From donn at avvanta.com  Tue Sep  1 01:13:54 2015
From: donn at avvanta.com (Donn Cave)
Date: Mon, 31 Aug 2015 18:13:54 -0700 (PDT)
Subject: [Haskell-cafe] side effects (Why Haskell is beautiful to
	thenovice)
In-Reply-To: <dab30c8192b9913fb92cce0c35c60d71.squirrel@chasm.otago.ac.nz>
References: <dab30c8192b9913fb92cce0c35c60d71.squirrel@chasm.otago.ac.nz>
Message-ID: <20150901011354.9F70B93C40@mail.avvanta.com>

quoth <ok at cs.otago.ac.nz>
...
> I see someone has changed it back to the old muddled wreck, sigh.

I sympathize with what I understand to be the point, that it's silly
to call an effect that's clearly central to a computation a "side effect."

That said, it sure is widely used that way, and an attempt to correct
this is not only swimming upstream, it also encounters ambiguities that
the common definition avoids.

Maybe it would be more productive to see this an opportunity to talk
about how FP and Haskell in particular organize effectful computations
to avoid the problems with side effects.

I think the FP paragraph on this page could be much better - "The
functional language Haskell expresses side effects such as I/O and
other stateful computations using monadic actions."  That's it?
Can this be written so it would address what Haskell brings to
the problem, in a way that would make sense to a Java programmer?

	Donn

From alex at farfromthere.net  Tue Sep  1 04:25:59 2015
From: alex at farfromthere.net (Alex Chapman)
Date: Tue, 01 Sep 2015 04:25:59 +0000
Subject: [Haskell-cafe] How to combine simulations
In-Reply-To: <55E48541.2030402@web.de>
References: <55E48541.2030402@web.de>
Message-ID: <CALSAsnDr0o9w_XyUPeZho7-heJyNB6w8Q3DcHSQabSaKuUnGZA@mail.gmail.com>

Hi Martin,

Here's a skeleton of one way you could do something like what you describe:

{-# LANGUAGE MultiParamTypeClasses #-}
module DES where

-- Typeclasses for sending and receiving events
class EventSender a e where
   send :: a -> e

class EventRecipient a e where
   receive :: a -> e -> a

-- Basic types: players and tables. These can be added to.
data Player = Player String
data Table = Table Int Player

-- Types of events: these can be added to.
data PlayerEvent = PlayerEvent Player
data OtherTableEvent = OtherTableEvent Table
data BallsAtRestEvent = BallsAtRestEvent

-- Players can send player events
instance EventSender Player PlayerEvent where
  send p = PlayerEvent p

-- Players can receive balls at rest events
instance EventRecipient Player BallsAtRestEvent where
  receive p _ = p -- TODO

-- Tables can receive player events
instance EventRecipient Table PlayerEvent where
  receive t _ = t -- TODO

-- Tables can send other table events
instance EventSender Table OtherTableEvent where
  send t = OtherTableEvent t

-- Tables can receive other table events
instance EventRecipient Table OtherTableEvent where
  receive t _ = t -- TODO

-- Now we combine two tables
data TableSystem = TableSystem (Table, Table)

-- The combined system only receives player events, and sends no events
instance EventRecipient TableSystem PlayerEvent where
  receive ts _ = ts -- TODO

Alex

On Tue, 1 Sep 2015 at 02:50 martin <martin.drautzburg at web.de> wrote:

> Hello all,
>
> I've been trying hard to come up with an idea how to build a DES from
> smaller parts. So far, I came to the conclusion,
> that somewhere there must be an operation which takes an Event and maybe
> emits an Event (and appends to a log and
> updates some state). Those Events whould come from and go to the
> "environment" the simulation runs in.
>
> My mental model is two billiard tables, which are connected through a hole
> in the cushion and which each have a player.
> When I look at one such table, it would have to respond to Events from its
> player and from the other table and it would
> send events to its player ("all balls at rest") and to the other table.
>
> If I add the other table and the two players then the combined simulation
> would not emit any events at all and it would
> not respond to any events except maybe as START event. It would only
> depend on its initial state.
>
> But if I add only the player, but not the other table, it would still send
> events to the other table and respond to
> events from that other table.
>
> My problem is the type of Events. I could create a type which encompasses
> all possible events, but that violates the
> idea of composablitly. Somehow I would need to be able to take a system
> which accepts "player events" and "other table
> events", compose it with an other table and end up with a system which
> only accepts "player events" but no more "other
> table events" and similarly for the emitted events. And I don't quite know
> how to do this.
>
> Hope this makes some sense.
>
> Any pointers (which go beyond "aivika has a simulation component") would
> also be much appreciated.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/f2281bbc/attachment.html>

From tdammers at gmail.com  Tue Sep  1 05:49:40 2015
From: tdammers at gmail.com (Tobias Dammers)
Date: Tue, 1 Sep 2015 07:49:40 +0200
Subject: [Haskell-cafe] side effects (Why Haskell is beautiful to
 thenovice)
In-Reply-To: <20150901011354.9F70B93C40@mail.avvanta.com>
References: <dab30c8192b9913fb92cce0c35c60d71.squirrel@chasm.otago.ac.nz>
 <20150901011354.9F70B93C40@mail.avvanta.com>
Message-ID: <20150901054939.GA24657@nibbler>

On Mon, Aug 31, 2015 at 06:13:54PM -0700, Donn Cave wrote:
> quoth <ok at cs.otago.ac.nz>
> ...
> > I see someone has changed it back to the old muddled wreck, sigh.
> 
> I sympathize with what I understand to be the point, that it's silly
> to call an effect that's clearly central to a computation a "side effect."
> 
> That said, it sure is widely used that way, and an attempt to correct
> this is not only swimming upstream, it also encounters ambiguities that
> the common definition avoids.

"Eat feces; billions of flies can't be wrong!"

Seriously though, the distinction between an *effect* and a *side
effect* is important, and using the term "side effect" to indicate
either is just as ambiguous.

> I think the FP paragraph on this page could be much better - "The
> functional language Haskell expresses side effects such as I/O and
> other stateful computations using monadic actions."  That's it?
> Can this be written so it would address what Haskell brings to
> the problem, in a way that would make sense to a Java programmer?

It could certainly be better; it's not only vague, but also misleading,
further fueling the Monad Confusion. Haskell expresses effects by making
them first-class, i.e., introducing values that represent the effects,
functions to combine and manipulate them in a pure fashion, and the
convention that the value bound to Main.main represents the computation
we want the runtime to execute. IO also happens to be a valid Monad
instance, but that's more a convenience thing, it's not essential to
encoding effects at all - one could easily implement an IO minilanguage
that doesn't implement Monad; it would end up taking a Monad shape at
some point though, so it makes sense to make it official by having it
implement the Monad typeclass. But that's not essential for the
mechanism at play here - it just so happens that effectful computations
usually end up forming monads.

From strake888 at gmail.com  Tue Sep  1 06:13:15 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Mon, 31 Aug 2015 22:13:15 -0800
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
Message-ID: <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>

On 31/08/2015 at 13:28:00 +1200, Richard A. O'Keefe wrote:
> 
> On 29/08/2015, at 4:17 pm, M Farkas-Dyck <strake888 at gmail.com> wrote:
> > 
> > Actually we ought to start with semiconductor physics, VLSI
> > fabrication, and such.
> > cuz that's how current computers work.
> 
> I did start a computer architecture lecture once
> with a 10 minute explanation of what a field effect
> transistor does.  The physicist in me was only partly
> appeased by the consideration that this was all the
> students were _ever_ going to be told about what was
> really going on underneath.  Some of the students
> thanked me for it.  Some,  didn't.

My comment was sarcastic actually. I mean we can teach computer science agnostic of particular implementations, at least to some degree.

Computer architecture, tho, is to my knowledge largely due to implementational constraints, so it seems quite appropriate to teach the foundational technologies at least briefly.

> As for Python, remember that the people who are praising
> Python as an initial language are probably comparing it
> with Java or C++.

I could compare Java and COBOL; it wouldn't make Java worthy.

From mwm at mired.org  Tue Sep  1 06:59:08 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 01 Sep 2015 06:59:08 +0000
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
Message-ID: <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>

On Tue, Sep 1, 2015 at 12:58 AM M Farkas-Dyck <strake888 at gmail.com> wrote:

> I could compare Java and COBOL; it wouldn't make Java worthy.
>

Of course not. There are application areas for which COBOL is clearly
superior to - and hence more worthy than - Java. Or Haskell.

You seem to be suffering from the common misconception that there is some
independent, objective measure of the quality of programming languages.
That simply is not the case. It will depend on any number of constraints.
For instance, much as I enjoy writing Haskell and appreciate it's virtues,
it is less worthy than C/C++ for many of my current projects for the simple
reason that Haskell code won't run on the processors those projects need to
run on.

The same goes for teaching an intro programming/CS/SE class. Your measure
of "worthy" will depend on your goals and audience. Do you want to
introduce programming as an art that can be criticized and enjoyed? Then
I'd say Haskell is clearly the choice you want to make. But if the goal is
to give the students a feel for what programing is like for most practicing
programmers today, then Haskell falls well behind many other languages. And
so on through a long list of other possible scenarios with there own
metrics of worth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/4f0e72e3/attachment.html>

From alexey.muranov at gmail.com  Tue Sep  1 07:47:55 2015
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Tue, 1 Sep 2015 09:47:55 +0200
Subject: [Haskell-cafe] side effects (Why Haskell is beautiful to
	thenovice)
In-Reply-To: <20150901054939.GA24657@nibbler>
References: <dab30c8192b9913fb92cce0c35c60d71.squirrel@chasm.otago.ac.nz>
 <20150901011354.9F70B93C40@mail.avvanta.com> <20150901054939.GA24657@nibbler>
Message-ID: <5080F530-3A2A-4E21-A377-2F8D88721988@gmail.com>

On 1 sept. 2015, at 07:49, Tobias Dammers <tdammers at gmail.com> wrote:

> Seriously though, the distinction between an *effect* and a *side
> effect* is important, and using the term "side effect" to indicate
> either is just as ambiguous.

Could you give an example of a side effect in programming, please?

Definition from Oxford dictionary:

  side effect -- a secondary, typically undesirable effect of a drug or medical treatment.

Since we are not talking about drugs but about programs, i fail to see any example of a "side effect" in the sense of this definition, other than, possibly, effects of bugs.

Previously my intuitive understanding of "side effects" in the sense of FP was quite clear: any effect that cannon happen if you execute the program in your mind or with pencil and paper, that is any interaction with the real world (think of programs as calculations).

I agree however that it was not clear if getting user input should be called a "side effect", or an oracle, or something else.

See also http://programmers.stackexchange.com/questions/40297/what-is-a-side-effect

Alexey.

From strake888 at gmail.com  Tue Sep  1 08:12:37 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Tue, 1 Sep 2015 00:12:37 -0800
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
Message-ID: <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>

On 31/08/2015, Mike Meyer <mwm at mired.org> wrote:
> Of course not. There are application areas for which COBOL is clearly
> superior to - and hence more worthy than - Java. Or Haskell.

Name one.

From agocorona at gmail.com  Tue Sep  1 08:16:15 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 1 Sep 2015 10:16:15 +0200
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
Message-ID: <CAArEJmaAOz5fUSwGkaT_WCYw4uEKQcWWBWKmxJtihKeO9nv6wQ@mail.gmail.com>

In general I think that haskell has a very low productivity because there
are too much distracting and the gap between the real problem and the
libraries is very high since there is a lot of abstraction in them.  In the
current state, even the haskell EDSLs are far from being close to their
respective domain problems, not because Haskell is not enough flexible, but
because it is too much flexible and too much abstract.

At last, a productive programming language must guide the programmer for
creating valid and efficient solutions fast. The haskell type system helps
in the first very well and this is a great advance, but it does not help on
the latter. There are too much alternatives, too much abstraction and with
a lot of impedance between them. All of this in combination with Monad
transformers and the abstruse errors kill any hope of making Haskell a
productive language.

Haskell is not a high level language in the usual sense, but an abstract
metalanguage where the gap between the platform and the concrete solution
is very long in terms of effort.

Still there is a need for an embedded general purpose high level language
in which a novice can start to program fast in Haskell by freely mixing
effects without a master in monad transformers, packages idiosyncrasies and
error intricacies.

 That is why I'm trying to create Transient: a flat monad with very high
level effects included, (upto distributed computing). That eliminates the
impedances and reduce complexity to a minimum level.

2015-09-01 8:59 GMT+02:00 Mike Meyer <mwm at mired.org>:

> On Tue, Sep 1, 2015 at 12:58 AM M Farkas-Dyck <strake888 at gmail.com> wrote:
>
>> I could compare Java and COBOL; it wouldn't make Java worthy.
>>
>
> Of course not. There are application areas for which COBOL is clearly
> superior to - and hence more worthy than - Java. Or Haskell.
>
> You seem to be suffering from the common misconception that there is some
> independent, objective measure of the quality of programming languages.
> That simply is not the case. It will depend on any number of constraints.
> For instance, much as I enjoy writing Haskell and appreciate it's virtues,
> it is less worthy than C/C++ for many of my current projects for the simple
> reason that Haskell code won't run on the processors those projects need to
> run on.
>
> The same goes for teaching an intro programming/CS/SE class. Your measure
> of "worthy" will depend on your goals and audience. Do you want to
> introduce programming as an art that can be criticized and enjoyed? Then
> I'd say Haskell is clearly the choice you want to make. But if the goal is
> to give the students a feel for what programing is like for most practicing
> programmers today, then Haskell falls well behind many other languages. And
> so on through a long list of other possible scenarios with there own
> metrics of worth.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/3d67db52/attachment.html>

From mwm at mired.org  Tue Sep  1 08:29:32 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 01 Sep 2015 08:29:32 +0000
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
Message-ID: <CAD=7U2CPE34PU_pvsfwWZmewTEBY0cgV=2tBM31f1ZpwF_iiUw@mail.gmail.com>

On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck <strake888 at gmail.com> wrote:

> On 31/08/2015, Mike Meyer <mwm at mired.org> wrote:
> > Of course not. There are application areas for which COBOL is clearly
> > superior to - and hence more worthy than - Java. Or Haskell.
> Name one.
>

Maintaining ~50-year old government systems that are written in COBOL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/16886c0f/attachment.html>

From semanticphilosopher at gmail.com  Tue Sep  1 08:33:46 2015
From: semanticphilosopher at gmail.com (Neil Davies)
Date: Tue, 1 Sep 2015 09:33:46 +0100
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAD=7U2CPE34PU_pvsfwWZmewTEBY0cgV=2tBM31f1ZpwF_iiUw@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
 <CAD=7U2CPE34PU_pvsfwWZmewTEBY0cgV=2tBM31f1ZpwF_iiUw@mail.gmail.com>
Message-ID: <9B8588D6-CDD5-428E-89AD-BF43103F7DE1@gmail.com>

Which, of course, leads us directly to: http://www.exit109.com/~ghealton/y2k/y2k_humor/Cobol.html .... :)
On 1 Sep 2015, at 09:29, Mike Meyer <mwm at mired.org> wrote:

> On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck <strake888 at gmail.com> wrote:
> On 31/08/2015, Mike Meyer <mwm at mired.org> wrote:
> > Of course not. There are application areas for which COBOL is clearly
> > superior to - and hence more worthy than - Java. Or Haskell.
> Name one.
> 
> Maintaining ~50-year old government systems that are written in COBOL.  
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/4fd72c22/attachment.html>

From miguelimo38 at yandex.ru  Tue Sep  1 08:40:02 2015
From: miguelimo38 at yandex.ru (Miguel Mitrofanov)
Date: Tue, 01 Sep 2015 11:40:02 +0300
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAD=7U2CPE34PU_pvsfwWZmewTEBY0cgV=2tBM31f1ZpwF_iiUw@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
 <CAD=7U2CPE34PU_pvsfwWZmewTEBY0cgV=2tBM31f1ZpwF_iiUw@mail.gmail.com>
Message-ID: <123941441096802@web2h.yandex.ru>

That's not very different from "being forced to use COBOL by your employer". Surely, I'll use one in this case (or quit), but it doesn't make it superior.

01.09.2015, 11:30, "Mike Meyer" <mwm at mired.org>:
> On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck <strake888 at gmail.com> wrote:
>> On 31/08/2015, Mike Meyer <mwm at mired.org> wrote:
>>> Of course not. There are application areas for which COBOL is clearly
>>> superior to - and hence more worthy than - Java. Or Haskell.
>> Name one.
>
> Maintaining ~50-year old government systems that are written in COBOL.
> ,
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From agocorona at gmail.com  Tue Sep  1 08:49:57 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 1 Sep 2015 10:49:57 +0200
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <123941441096802@web2h.yandex.ru>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
 <CAD=7U2CPE34PU_pvsfwWZmewTEBY0cgV=2tBM31f1ZpwF_iiUw@mail.gmail.com>
 <123941441096802@web2h.yandex.ru>
Message-ID: <CAArEJmZ96P1a-8XcWVYeak7QRmO7k1sUevqsX9ACM6+WkgJyVw@mail.gmail.com>

COBOL is verbose but at least it is easy to understand. but the current
practices in enterprise java programming make legacy Java code verbose,
complicated, low level and impossible to understand without profuse
documentation, diagrams, web references etc. That documentation will
disappear sooner or latter...

2015-09-01 10:40 GMT+02:00 Miguel Mitrofanov <miguelimo38 at yandex.ru>:

> That's not very different from "being forced to use COBOL by your
> employer". Surely, I'll use one in this case (or quit), but it doesn't make
> it superior.
>
> 01.09.2015, 11:30, "Mike Meyer" <mwm at mired.org>:
> > On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck <strake888 at gmail.com>
> wrote:
> >> On 31/08/2015, Mike Meyer <mwm at mired.org> wrote:
> >>> Of course not. There are application areas for which COBOL is clearly
> >>> superior to - and hence more worthy than - Java. Or Haskell.
> >> Name one.
> >
> > Maintaining ~50-year old government systems that are written in COBOL.
> > ,
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/7e50ebd1/attachment.html>

From semanticphilosopher at gmail.com  Tue Sep  1 09:05:21 2015
From: semanticphilosopher at gmail.com (Neil Davies)
Date: Tue, 1 Sep 2015 10:05:21 +0100
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAArEJmZ96P1a-8XcWVYeak7QRmO7k1sUevqsX9ACM6+WkgJyVw@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
 <CAD=7U2CPE34PU_pvsfwWZmewTEBY0cgV=2tBM31f1ZpwF_iiUw@mail.gmail.com>
 <123941441096802@web2h.yandex.ru>
 <CAArEJmZ96P1a-8XcWVYeak7QRmO7k1sUevqsX9ACM6+WkgJyVw@mail.gmail.com>
Message-ID: <144A1090-CCBD-47B1-AF0A-469E8102C0AB@gmail.com>

Don't confuse "easy to read" with "easy to understand" with "easy to reason about" with "easy to prove" 

Long term  support is not about the language, it is about the ability to take someone new to become suitably engaged with the system to diagnose, repair and extend.

To reason about cobol programs you need to reason about them in the context of not just the programming language, but also the compiler peculiarities, the o/s environment etc. 

This is a *lot* easier in Haskell than in most environments - not perfect. Haskell has strictly defined areas of doubt and uncertainty that you know you have to engage with, in other languages the doubt and uncertainty is no where nearly as well contained.

On 1 Sep 2015, at 09:49, Alberto G. Corona <agocorona at gmail.com> wrote:

> COBOL is verbose but at least it is easy to understand. but the current practices in enterprise java programming make legacy Java code verbose, complicated, low level and impossible to understand without profuse documentation, diagrams, web references etc. That documentation will disappear sooner or latter...
> 
> 2015-09-01 10:40 GMT+02:00 Miguel Mitrofanov <miguelimo38 at yandex.ru>:
> That's not very different from "being forced to use COBOL by your employer". Surely, I'll use one in this case (or quit), but it doesn't make it superior.
> 
> 01.09.2015, 11:30, "Mike Meyer" <mwm at mired.org>:
> > On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck <strake888 at gmail.com> wrote:
> >> On 31/08/2015, Mike Meyer <mwm at mired.org> wrote:
> >>> Of course not. There are application areas for which COBOL is clearly
> >>> superior to - and hence more worthy than - Java. Or Haskell.
> >> Name one.
> >
> > Maintaining ~50-year old government systems that are written in COBOL.
> > ,
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
> 
> 
> -- 
> Alberto.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/1d6349d3/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Tue Sep  1 10:30:28 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 1 Sep 2015 12:30:28 +0200
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
Message-ID: <55E57E44.90105@unicaen.fr>


Le 01/09/2015 08:59, Mike Meyer a ?crit :
> There are application areas for which COBOL is clearly superior to - 
> and hence more worthy than - Java. Or Haskell.

Perhaps.
But could you

1. Tell us which application areas? Concretely.
2. Explain what does it mean "superior"?
3. Explain WHY Java is inferior?


Jerzy Karczmarczuk
/Caen, France/


From agocorona at gmail.com  Tue Sep  1 10:55:45 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 1 Sep 2015 12:55:45 +0200
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <55E57E44.90105@unicaen.fr>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <55E57E44.90105@unicaen.fr>
Message-ID: <CAArEJmY4yn3EbZniPEsCrcOu6pUEzQtvZ8N=rX6jAOf7qpcRYQ@mail.gmail.com>

COBOL is at least an honest language, while Java-J2EE is an standard
initially made by SUN and the big ones for selling monstruous servers to
big departments which contract big consultancy companies for very long time
as well as very expensive application servers.

Java-J2EE was exactly what the mainframe server and the big consultancy
firms and the big software departments of big companies needed to justify
and maintain and augment their big budgets in the transition from
mainframes to the "internet age"

2015-09-01 12:30 GMT+02:00 Jerzy Karczmarczuk <jerzy.karczmarczuk at unicaen.fr
>:

>
> Le 01/09/2015 08:59, Mike Meyer a ?crit :
>
>> There are application areas for which COBOL is clearly superior to - and
>> hence more worthy than - Java. Or Haskell.
>>
>
> Perhaps.
> But could you
>
> 1. Tell us which application areas? Concretely.
> 2. Explain what does it mean "superior"?
> 3. Explain WHY Java is inferior?
>
>
> Jerzy Karczmarczuk
> /Caen, France/
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/13b119f5/attachment-0001.html>

From jim.crayne at gmail.com  Tue Sep  1 11:02:50 2015
From: jim.crayne at gmail.com (James Crayne)
Date: Tue, 1 Sep 2015 11:02:50 +0000
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
Message-ID: <CANP7-dS6kfpyO4DEfXqnRXPQkg+7+R7tTnrC410-TFEBWtwoBA@mail.gmail.com>

I think early on in the development of the language, a decision was made
that it was nice if we can express the concepts in a way that was close to
how we would on paper, even if it meant that the parser can or would be
very complicated. A decided break with the lisp crowd was made in this
respect. Initially, i think, even performance was considered a distant
second to this.

Also, what we tend to call "abstract" is actually often just "cleaned up"
as in, we are using the word as a euphemism for "clutter removed".

Somewhat worryingly, but also understandably, the stress and emphasis
placed on these values has actually lessoned over time, due to other
important values becoming greater.

As language creators, we set the tone for the entire industry, or at least
everyone working in our language. As a result, I would argue that people
who program in haskell place a great deal more energy and care into how
they express their code.

Haskell for a long time was used primarily by academics, and their
students, so arguably its primary purpose was this expression, where as
most other languages are invented for purely practical reasons and dwelling
on exactly the right syntax might have been seen as a sort of endless bike
shedding to be avoided, so that ultimately the practical concerns are
addressed.

There are likely some objective measures of clutter even without knowing
the specific problems at hand. How much do unrelated concepts blend
together in the text, and so on. In c and c++, you really have a bit of
boiler plate on every program, you can see this by comparing "hello world!"
in these languages. Naturally, all those tokens on the screen that must be
included in every program have very little to do with the actual underlying
algorithm, or functionality.

Consider what the equivalent of sum types and product types and sums of
product types look like in these languages. I think a very strong case can
be made that Haskell is _objectively_ more "beautiful" than these
languages, and if I am correct, even a complete novice will be able to
discern this, given the examples to demonstrate.

James C

On Thu, Aug 27, 2015 at 9:08 PM, Olaf Klinke <olf at aatal-apotheke.de> wrote:

> Dear cafe,
>
> please correct me if questions like this should not go via this mailing
> list.
> Presumably everyone on this list agrees that Haskell stands out as a
> beautiful and pleasant language to have. The recent nitpicking and
> real-world problems like cabal hell don't change that. However, statements
> supporting Haskell's beauty usually involve: "In Haskell it is so much
> clearer/easier/faster to ... than in another language." That is, the beauty
> of Haskell presents itself to those who can compare it to other imperative
> or not strongly typed languages that one learned before Haskell.
> My question is, for what reason should anyone not acquainted with any
> programming language find Haskell beautiful? Maybe it does not look
> beautiful at all to the novice. The novice can not draw on the comparison,
> unless he takes the effort to learn more than one language in parallel. The
> novice likely also does not have the mathematical background to see the
> beautiful correspondence between the language and its semantics. (My reason
> to love FP is because it is executable domain theory.) One might argue that
> it is not the language itself that is beautiful, but rather the concepts
> (data structures, algorithms, recursion) and Haskell does a great job to
> preserve their beauty into the implementation. Do you agree?
>
> Disclaimer: I am about to start teaching a first course in computer
> science in secondary school. I can teach whatever I want, since this is the
> first CS course the school ever had. I want to teach beautiful things. I
> love functional programming. I need not start teaching programming right
> away. But I am reluctant to expose the pupils to something whose beauty
> escapes them completely.
>
> -- Olaf
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/41d661e4/attachment.html>

From donn at avvanta.com  Tue Sep  1 15:05:03 2015
From: donn at avvanta.com (Donn Cave)
Date: Tue,  1 Sep 2015 08:05:03 -0700 (PDT)
Subject: [Haskell-cafe] side effects (Why Haskell is beautiful
	tothenovice)
In-Reply-To: <20150901054939.GA24657@nibbler>
References: <dab30c8192b9913fb92cce0c35c60d71.squirrel@chasm.otago.ac.nz>
 <20150901011354.9F70B93C40@mail.avvanta.com>
 <20150901054939.GA24657@nibbler>
Message-ID: <20150901150503.D181493C2E@mail.avvanta.com>

Quoth Tobias Dammers <tdammers at gmail.com>,
> On Mon, Aug 31, 2015 at 06:13:54PM -0700, Donn Cave wrote:

> Seriously though, the distinction between an *effect* and a *side
> effect* is important, and using the term "side effect" to indicate
> either is just as ambiguous.

It isn't, because they avoid the matter of intent.  If you call
every change to state context a side effect, then you're down
to fine points about state, context, etc.

Anyone can see the importance of a distinction between effect
and side effect, but that doesn't make it easy to draw up a
definition that could easily be applied to any expression to
tell us whether the effect is a side effect or not.

Rather what I'm saying is, let the billions of flies have it
their way, but use the FP paragraph to illustrate more appealing
culinary techniques for clean and wholesome dining.  Functional
languages are by nature less dependent on side effects, with
features like single assignment, efficent recursion, am I right?

I agree with your thought to deemphasize the monad part of the
Haskell explanation.  It might be a mistake to try to really
explain how Haskell does it, maybe better to just say that
Haskell rigorously distinguishes expressions that have external
side effects and provides a mechanism for their ordered execution.
If you get too deep into it, you have to explain that, well, IO
isn't just for side effects but accounts for any external state
dependency, etc. - and all in terms that will easily be understood
by an average Java programmer.  (That's why I'm pursuing this,
in my position as surely the least erudite member of this
mailing list, I hope to be able to recognize a suitably simple
minded explanation when I see one.)

	DOnn

From mwm at mired.org  Tue Sep  1 15:41:57 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 01 Sep 2015 15:41:57 +0000
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <55E57E44.90105@unicaen.fr>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <55E57E44.90105@unicaen.fr>
Message-ID: <CAD=7U2CSQVu0Y1uyhL6iVoBphORftnsVNVOqGApXirszRoEL0Q@mail.gmail.com>

On Tue, Sep 1, 2015 at 6:30 AM Jerzy Karczmarczuk <
jerzy.karczmarczuk at unicaen.fr> wrote:

>
> Le 01/09/2015 08:59, Mike Meyer a ?crit :
> > There are application areas for which COBOL is clearly superior to -
> > and hence more worthy than - Java. Or Haskell.
>
> Perhaps.
> But could you
>
> 1. Tell us which application areas? Concretely.
> 2. Explain what does it mean "superior"?
> 3. Explain WHY Java is inferior?
>

Since you asked nicely, I'll explain my earlier one-liner.

First, a language is "superior" (or "more worthy") if it fails to meet the
constraints of the problem at hand, or if a constraint is the optimization
of a measurable quantity, and solutions using that language will clearly
have better values for that quantity than an inferior language choice.

In the real world, problems often come with a legacy code base of some
kind. In which case, optimizing cost or development time - or possibly even
performance of the code, depending on the languages in question - may well
involve using the legacy code base. You see such decision everywhere in the
Haskell ecosystem, from compilers that generate C code instead of native
code, to wrappers that wrap FORTRAN number-crunching systems.

And an apology. When I wrote "government systems" last night, I was
searching for a short way to describe a complex issue, and failed to
recognize the ambiguity in the phrase and that the most likely
interpretation wasn't the one I had in mind.

I meant systems whose output was determined in large part by a large body
of government regulations. For instance, anything that deals with
calculating taxes.  This stuff not only has vague and confusing
specifications in the form of regulations written by legislators, but it
tends to be revised every year, without the developers of such systems
being consulted.

So in this case, your legacy code is not merely decades old, but has been
undergoing revision for decades.

One of the strengths of COBOL is the ability to deal with data files in
formats that were in common use by businesses when the system was designed.
Given that these problems are often CRUD of some sort or another, these
features tend to be heavily used in such systems.

The output formats we've pretty much kept - the people reading them were
happy, and didn't want them to change. COBOL's ability to generate reports
using them was good, and I don't believe Haskell has any comparable
functionality. Java doesn't seem to have it in the "official" libraries,
but there are third party report generation tools that are probably better.
Except you have to write your report specification on Java, or worse yet
XML - which is so bad you probably get a tool for creating them.

Input, on the other hand, is a mess. Nobody in their right minds would use
the input formats COBOL can deal with - we've learned a lot about making
input easier on humans since then (XML wasn't designed to for human input;
it's SGML stripped down to the point where merely competent programmers can
 write a correct parser). But if you're dealing with such legacy systems,
you've probably got data files in those old formats. Sure, java re's or
Haskell's parser combinator libraries make writing parsers for those - or
better yet, sane - formats possible, but COBOL does it natively.

While we're talking about native features, COBOL's native formats were
designed for dealing with money - which is often the data type such systems
have to deal with. Last time I looked - about a year or so ago - Haskell
didn't have a high quality data type for doing that. Java probably does,
but not as a native type. And this makes wrapping the legacy code an
interesting proposition - what do you map a data item declared as "PIC
9(8).99" to?

Ok, that's the problem and some of the issues that with it. The
optimization constraint is, of course, to minimize the cost of ongoing
maintenance over a relatively short term, say a couple of years.

And for the record, I've known people whose job was maintaining just such
systems. When given a problem that involved low-level bit-twiddling, or
creating linked lists as discussed earlier, they quite happily started
writing a WORKING-STORAGE section.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/82fb227e/attachment.html>

From rustompmody at gmail.com  Tue Sep  1 17:34:22 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Tue, 1 Sep 2015 23:04:22 +0530
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <CAL3m8eCA6OJgH6TfLGtJke7GKxO9HeUZQJHZ2mb-Jyj8f3ww0A@mail.gmail.com>
Message-ID: <CAJ+TeoeSS+uZoaZAkgqW2-KirysseEZ686MbTg_GjCnjaQBR7A@mail.gmail.com>

On Tue, Sep 1, 2015 at 1:42 PM, M Farkas-Dyck <strake888 at gmail.com> wrote:

> On 31/08/2015, Mike Meyer <mwm at mired.org> wrote:
> > Of course not. There are application areas for which COBOL is clearly
> > superior to - and hence more worthy than - Java. Or Haskell.
>
> Name one.
>

When what you mean by 'file' is this
https://en.wikipedia.org/wiki/Data_set_%28IBM_mainframe%29
Cobol is unbeatable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/a3b51c4d/attachment.html>

From rustompmody at gmail.com  Tue Sep  1 17:53:19 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Tue, 1 Sep 2015 23:23:19 +0530
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <C39ACD0F-D325-4B8A-A0E3-800987F81781@gmail.com>
References: <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <20150829060950.83DCB276D62@mail.avvanta.com>
 <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com>
 <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz>
 <CAG8oi1OmFjDcjNTMapdCJe0J+T6srT60xBe785bq-oF-Q3qBtg@mail.gmail.com>
 <FDFFEEC3-3317-489D-8EBC-001B1142CB5E@cs.otago.ac.nz>
 <C39ACD0F-D325-4B8A-A0E3-800987F81781@gmail.com>
Message-ID: <CAJ+TeoeVZ8n=UGOneiS=ma3G7LBPvbe+n277AF6c-t+DqK9MpQ@mail.gmail.com>

On Mon, Aug 31, 2015 at 1:57 PM, Alexey Muranov <alexey.muranov at gmail.com>
wrote:

> On 31 ao?t 2015, at 06:11, Richard A. O'Keefe <ok at cs.otago.ac.nz> wrote:
>
> > Sorry, cliekd the wrong button.
> > If you had troubled to read the Wikipedia article with care,
> > you'd have seen this right at the beginning:
> >
> >       In computer science, a function or expression is
> >                                      VVVVVVVVVVVVVVVVVVVVVVVV
> >       said to have a side effect if, in addition to returning
> >                                      ^^^^^^^^^^^^^^^^^^^^^^^^
> >       a value, it also modifies some state or has an observable
> >       interaction with calling functions or the outside world.
> >
> > You have a function, whose purported effect is to return a
> > value.  "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE",
> > "A SECONDARY RESULT".
>
> In my opinion, with such interpretation there can be no documented side
> effects: if some effect is documented, it is purported (an probably used by
> someone), so not secondary.
>
>
I think this argument represents a generation gap:
Those  brought up on Pascal will find it obvious what Richard (is trying)
to say:
- a function either just returns a value or has side-effects
- a procedure has effects -- nothing 'on the side' here.

Unfortunately C screwed up a whole generation by removing this distinction
from our thinking ontologies
And the languages that have followed C are often worse eg python's None
return is more ambiguous than C's void return
eg. Ive found experienced python programmers dont understand that the
'procedure' appellation can only be applied to to functions that ALWAYS
return None

One could say that Haskell's monadic types reinstates Pascal's dichotomy

More on this here:
http://blog.languager.org/2015/06/functional-programming-moving-target.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/df62b695/attachment.html>

From ok at cs.otago.ac.nz  Tue Sep  1 23:34:32 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Wed, 2 Sep 2015 11:34:32 +1200
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <C39ACD0F-D325-4B8A-A0E3-800987F81781@gmail.com>
References: <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <20150829060950.83DCB276D62@mail.avvanta.com>
 <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com>
 <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz>
 <CAG8oi1OmFjDcjNTMapdCJe0J+T6srT60xBe785bq-oF-Q3qBtg@mail.gmail.com>
 <FDFFEEC3-3317-489D-8EBC-001B1142CB5E@cs.otago.ac.nz>
 <C39ACD0F-D325-4B8A-A0E3-800987F81781@gmail.com>
Message-ID: <55474971-DE7D-4F7F-9F04-9AA4351D827D@cs.otago.ac.nz>


On 31/08/2015, at 8:27 pm, Alexey Muranov <alexey.muranov at gmail.com> wrote:
> 
> In my opinion, with such interpretation there can be no documented side effects: if some effect is documented, it is purported (an probably used by someone), so not secondary.

Let's see a piece of actual Java code, not written by me.

public class Record {
    private static final AtomicLongFieldUpdater<Record> VERSION =
        AtomicLongFieldUpdater.newUpdater(Record.class, "version");

    private volatile long version = 0;

    public long update() {
        return VERSION.incrementAndGet(this);  // THIS LINE IN JAVA
    }
}

For comparison, here's basically the same thing in C on OSX:

struct Record {
    volatile int64_t version = 0;
};

// Atomic this->version++
int64_t update(struct Record *this) {
    return OSAtomicIncrement64(&this->version);  // THIS LINE IN C
}

THIS LINE IN C has an effect.   It's obvious from the code
that the variable `version' may be affected.

THIS LINE IN JAVA doesn't as much as mention `version'.

Surely there is a qualitative difference here that *matters*?

Historic note:  Java forbade 'var' or 'reference' parameters
in the name of object-oriented purity.  i have never been able
to figure out what they meant.  What they have instead is, and
I kid you not, AtomicLongFieldUpdate is an official Java public
class, is POINTER ARITHMETIC.  (AtomicLongFieldUpdater basically
holds a reference to a class and an offset within that class,
which gets added to the argument to find the actual variable.)

I just learned about AtomicLongFieldUpdater yesterday and still
feel sick.  Java just moved from "I don't particularly like it
but it could be worse" to "heck, I might as well just use C" in
my estimation.  What I am still having difficulty swallowing is
the Java enthusiasts who think this feature is wonderful.

But this is a Haskell mailing list, not a Java or C one.
For *Haskell*, the type system doesn't encode *all* the
effects of an operation (although a functional language
type system *could* do so), but it forces you to reveal
that an operation has *some* effect other than returning
a value and *encourages* you to factor your state space
into chunks smaller than the whole world.  If you have two
state monads and you need to update both, you *know* you
have an issue.





From ok at cs.otago.ac.nz  Wed Sep  2 03:23:27 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Wed, 2 Sep 2015 15:23:27 +1200
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <CAD=7U2CSQVu0Y1uyhL6iVoBphORftnsVNVOqGApXirszRoEL0Q@mail.gmail.com>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <55E57E44.90105@unicaen.fr>
 <CAD=7U2CSQVu0Y1uyhL6iVoBphORftnsVNVOqGApXirszRoEL0Q@mail.gmail.com>
Message-ID: <6679B1E7-0987-451E-9C63-DE99562CF1B6@cs.otago.ac.nz>

If anyone wants to talk about COBOL,
it's worth remembering that there have been several major
versions of COBOL with major differences.
COBOL 68 was, well, meh.
COBOL 74 was quite a dramatic improvement,
arguably bigger than Fortran 66 -> Fortran 77.
COBOL 85 was another dramatic improvement,
finally permitting structured programming
with user-defined procedures.  About comparable
to the Fortran 77 -> Fortran 90 jump, where
Fortran got free format, full set of structured
programming structures, modules, nested procedures,
and other good stuff.

COBOL development did not stop there.
COBOL 2002 added free format, user defined functions
(that is, usable expressions), recursion (just 42 years
after Algol 60...), locales, Unicode, a Boolean data type,
pointers, form-based screen interfaces.  Oh, and object
orientation!  I have to say that OO COBOL is in my view
uniquely horrible.., but this is not the place to defend
that view.
COBOL 2014 added native support (seriously weird native
support, but native support) for XML, and a set of
container classes (these had been issued by 2009).

One of the merits of COBOL 85 was that the language lacked
features that make static analysis difficult, so it was
possible to analyse COBOL programs quite thoroughly.
The additions to COBOL 2002 have pretty comprehensively
destroyed that property, without making COBOL into anything
an OO programmer would really _want_ to use.  Perhaps it is
not surprising that a large amount of COBOL code is still
said to be fairly straight COBOL 85, even COBOL 74.

The non-business world seems to mostly thinks of COBOL as if
it were still 1970, such as the non-heavy-duty-numerics world
seems to still think of Fortran as if it were still 1970.

Back when it *was* the 1970s, COBOL enjoyed a good reputation
for portability, which more academically favoured languages
by and large did not.  Much of this comes down to arithmetic:
    77 MY-COUNT PICTURE S999999 USAGE COMPUTATIONAL.
makes it clear that I want something that can hold at least
-999,999 .. +999,999 that's good for calculating with, and
the rules of COBOL say that I *must* get it, even on a 16-bit
machine.  In contrast, if I write
      INTEGER MYCNT                 -- Fortran
or    var mycount: integer;         -- Pascal
then I get what I'm given, and even if I ask for
      var mycount: -999999 .. 999999;
a Pascal compiler is under no obligation to satisfy me.

So COBOL gave accountants portable decimal arithmetic on
numbers of up to 18 digits (now 31), *regardless* of the
underlying machine. With overflow detection a *standard*
feature (still not available in Java or C#).

Commercial COBOL compilers have got very good at what they
do, and the idea of replacing a COBOL program working on
COBOL-like data by a Java program using BigDecimal is not
one that appeals unless you are desperate to slow down a
computer that's too fast.

Of course, nothing says you couldn't have a decent
structured modular programming language with strong static
typing that was capable of working on COBOL data.  It's
called Ada.    And again, nothing stops someone making a
nice structured language whose compiler targets COBOL.

Come to think of it, there's no reason there couldn't be
a Haskell compiler with really efficient support for
fixed-point decimal numbers.  It just seems unlikely that
Haskell programmers would want it.

As other people have noted, sometimes the environment of a
language is as important as the language itself.  I've never
used Eclipse -- though I've tried and failed -- but Eclipse
support for COBOL is said to be excellent.



From david.sorokin at gmail.com  Wed Sep  2 07:35:19 2015
From: david.sorokin at gmail.com (David Sorokin)
Date: Wed, 2 Sep 2015 10:35:19 +0300
Subject: [Haskell-cafe] Fwd:  How to combine simulations
In-Reply-To: <CAFJaeuNj-dKciHV+FQ+VJf_bhbBZj0tBh+gjVMbtZE2jThBjTA@mail.gmail.com>
References: <55E48541.2030402@web.de>
 <CAFJaeuNj-dKciHV+FQ+VJf_bhbBZj0tBh+gjVMbtZE2jThBjTA@mail.gmail.com>
Message-ID: <CAFJaeuNggss_=YshBdY3a+bP643yqoOKqrfMh8nxq_ybX+_HBQ@mail.gmail.com>

Hi all,

I forgot to click on ReplyAll. I thought that my answer could be interested
to others as well. Therefore, I resend the letter to Haskell Cafe.

Thanks,
David


---------- Forwarded message ----------
From: David Sorokin <david.sorokin at gmail.com>
Date: Wed, Sep 2, 2015 at 9:39 AM
Subject: Re: [Haskell-cafe] How to combine simulations
To: martin <martin.drautzburg at web.de>


Hi Martin,

Nevertheless, regarding Aivika, did you look at the Signal type (inspired
by the IObservable interface of .NET)? This type is quite composable. If I
understood you correctly, the Signal is what you call Event.

Moreover, if you need a mutable state, then you could use the Ref reference
and its signal refChanged. For example, the reference could be used to
decide whether to emit a signal based on the intermediate state.

Furthermore, if you want to build a computation with linear-looking signal
processing then you could use the Process monad (inspired by the Async
workflow of F#) and the processAwait function that suspends the
current discontinuous process waiting for a signal to come.

I hope it helps. In case of need, these ideas can be re-implemented.

Thanks,
David

On Mon, Aug 31, 2015 at 7:48 PM, martin <martin.drautzburg at web.de> wrote:

> Hello all,
>
> I've been trying hard to come up with an idea how to build a DES from
> smaller parts. So far, I came to the conclusion,
> that somewhere there must be an operation which takes an Event and maybe
> emits an Event (and appends to a log and
> updates some state). Those Events whould come from and go to the
> "environment" the simulation runs in.
>
> My mental model is two billiard tables, which are connected through a hole
> in the cushion and which each have a player.
> When I look at one such table, it would have to respond to Events from its
> player and from the other table and it would
> send events to its player ("all balls at rest") and to the other table.
>
> If I add the other table and the two players then the combined simulation
> would not emit any events at all and it would
> not respond to any events except maybe as START event. It would only
> depend on its initial state.
>
> But if I add only the player, but not the other table, it would still send
> events to the other table and respond to
> events from that other table.
>
> My problem is the type of Events. I could create a type which encompasses
> all possible events, but that violates the
> idea of composablitly. Somehow I would need to be able to take a system
> which accepts "player events" and "other table
> events", compose it with an other table and end up with a system which
> only accepts "player events" but no more "other
> table events" and similarly for the emitted events. And I don't quite know
> how to do this.
>
> Hope this makes some sense.
>
> Any pointers (which go beyond "aivika has a simulation component") would
> also be much appreciated.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/fca1e8e8/attachment.html>

From jobs at create-net.org  Wed Sep  2 10:40:41 2015
From: jobs at create-net.org (CREATE-NET Jobs)
Date: Wed, 2 Sep 2015 12:40:41 +0200
Subject: [Haskell-cafe] JOB OPPORTUNITY_ Jr. Functional Software Developer
Message-ID: <CAH9n49B90gtSTF2rqVgJHY+aXM_n5i2MHRS9pOWwF8HUNaCbUA@mail.gmail.com>

CREATE-NET is seeking a motivated Junior Functional Software Developer. You
will be part our innovation IT team based in Trento, Italy, and will be
contributing to the development and testing of our specialized software
products which support the workflow related to scientific content
organization.

 *Technical skills*

?        Experience with one or more functional programming languages.
Haskell and Common Lisp are preferable.

?        Experience with web technologies: Javascript, HTML5, CSS, AJAX,
JSON APIs, web services, responsive web design.

?        Optional knowledge of either Node.js, Ruby on Rails, PHP, Java is
considered a plus

?        Experience with relational DBMSs (PostgreSQL)

?        Experience with distributed version control systems (Git)

?        Familiarity in working with GNU/Linux environments (RHEL, Ubuntu,
etc.)



*Specific job responsibilities will include*

?        Contributing to the maintenance and the improvement of our content
management platforms and applications;

?        Developing new solutions for software integration

?        Interacting with the project responsible and the user community to
determine requirements and communicating with the support team to handle
issues or new features requests.



*Organizational skills*

?        Autonomous thinking and problem solving skills;

?        Prioritization, time management skills and capability to adapt to
dynamic environments;

?        Ability to work hands-on and with little supervision;

?        Ability to timely deliver your work as per an agreed roadmap;

?        Attitude to collaborative working;



Applicants should have Bachelor?s degree (or equivalent experience) in
computing or other related disciplines and a proven experience in software
development. They should be enthusiastic about web applications
technologies and willing to expand their knowledge and skills on other
technologies too.

Please include any Github/Bitbucket or otherwise links to open-source
contributions you have made.



*How to Apply: *Please send your resume/CV in English to
careers at create-net.org, specifying in the email subject: ?FUNCTIONAL
SOFTWARE DEVELOPER -HC?. Only applications submitted in English will be
taken into consideration.

*Important:* Due to Italian Privacy Protection Law n.196/03 any resume not
mentioning explicitly the following wording: ?I authorize the use of my
personal data in accordance with Italian Privacy Protection Law
(30/06/2003, n.196/03)? will be automatically deleted from our database and
consequently not taken into consideration.

*Languages:* Good command of the English language (written and spoken) is
essential. Knowledge of the Italian language both spoken and written is not
required, but can be helpful.

*Working Place*: Povo (Trento), Italy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/2cb3cbbb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JR.FUNCTIONAL SOFTWARE DEVELOPER.pdf
Type: application/pdf
Size: 140583 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/2cb3cbbb/attachment-0001.pdf>

From jobs at create-net.org  Wed Sep  2 10:40:45 2015
From: jobs at create-net.org (CREATE-NET Jobs)
Date: Wed, 2 Sep 2015 12:40:45 +0200
Subject: [Haskell-cafe] JOB OPPORTUNITY_ IT Software Developer
Message-ID: <CAH9n49C+6CCjJB=oeU+Kwii=XsX4Zf=O_woFXRThdaCR5Lx4xQ@mail.gmail.com>

CREATE-NET is seeking a Software Developer passionate about web
applications development and its latest technologies. You will be part of
our Innovation IT team based in Trento, Italy and will contribute to the
development and testing of our portfolio of specialized software products
for supporting the promotion and education of Create-Net innovation result.


*Technical skills*

?     Working experience with HTML5, CSS, AJAX, JSON APIs, JavaScript

?     Working experience with Ruby (on Rails) and PHP plus some knowledge
about Java and Node.js

?     Knowledge of Mobile application development (Native Android/iOs or
PhoneGap/Cordova) and Responsive Web Design

?     Knowledge or interest of functional programming languages (Haskell,
Common Lisp, others) will be considered a strong plus

?     Experience with relational DBMSs (PostgreSQL in particular)

?     Experience with distributed version control systems such as Git

?     Familiarity working with Linux environments (Redhat, Ubuntu)

?     Experience and knowledge of agile methodologies, software design
methods are also considered a plus.

*Specific Job responsibilities will include:*

?     Contribution to the maintenance and evolution of existing tools which
support e-learning and virtual incubation (community portal, tasks
management app, event mobile app, idea-incubation/learning platform)

?     Contribution to the development of new solutions for software
integration

?     Contribution to technical support.

*Organization skills*

?     Autonomous thinking and problem solving skills;

?     Prioritization, time management skills and capability to adapt to
dynamic environments;

?     Ability to work hands-on and with little supervision;

?     Attitude to collaborative working.



Applicants should have Bachelor's degree (or equivalent experience) in
computing or other related disciplines and a proven experience in web
software development. They should be enthusiastic about web applications
technologies, open-minded and willing to share and expand their knowledge
and skills on other technologies too.



Please include any Github/Bitbucket or otherwise links to open source
contributions you have made.



*HOW TO APPLY:* Please send your resume/CV in English to
careers at create-net.org, specifying in the email subject: ?IT SOFTWARE
DEVELOPER_HC?. Only applications submitted in English will be taken into
consideration.
*Important:* due to Italian Privacy Protection Law n.196/03 any resume not
mentioning explicitly the following wording: ?I authorize the use of my
personal data in accordance with Italian Privacy Protection Law
(30/06/2003, n.196/03)? will be automatically deleted from our database and
consequently not taken into consideration.
*Languages:*  Excellent command of the English language (written and
spoken) is essential. knowledge of the Italian language both spoken and
written is not required, but can be helpful.
*Working Place*: Povo (Trento), Italy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/54de5726/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IT SOFTWARE DEVELOPER.pdf
Type: application/pdf
Size: 179706 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/54de5726/attachment-0001.pdf>

From k-bx at k-bx.com  Wed Sep  2 18:44:21 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Wed, 2 Sep 2015 21:44:21 +0300
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
Message-ID: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>

This is a call for comments before I'd create a ticket in corresponding
project (I'm not sure if it should be ghc or stack/cabal).

There's a common situation I get into: I compile with "stack build" (or
cabal build), get a big list of warnings, fix few of them, then I
re-compile project, but a lot of warnings are gone now. The only option I'm
left with is to use "-fforce-recomp".

Problems with -fforce-recomp are:
- full-recompile is quite long for big projects
- most people don't know about it, especially newbies

I think some flag, which would be turned on by default, which would
indicate to "recompile modules if they previously had warnings" would be
awesome to have.

1. would you like to have that flag?
2. would you like it "on" by default?
3. should ticket go into ghc or stack/cabal-install project?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/002d0081/attachment.html>

From fa-ml at ariis.it  Wed Sep  2 19:29:20 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Wed, 2 Sep 2015 21:29:20 +0200
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
Message-ID: <20150902192920.GA7423@casa.casa>

On Wed, Sep 02, 2015 at 09:44:21PM +0300, Kostiantyn Rybnikov wrote:
> I think some flag, which would be turned on by default, which would
> indicate to "recompile modules if they previously had warnings" would be
> awesome to have.
> 
> 1. would you like to have that flag?
> 2. would you like it "on" by default?
> 3. should ticket go into ghc or stack/cabal-install project?
> 
> Thank you.

I use often invoke ghc with `-Wall` and have experienced the same
problem. I would like to have such a flag (off by default).
I *think* the correct place where to implement this would be ghc.

From heraldhoi at gmail.com  Wed Sep  2 19:33:36 2015
From: heraldhoi at gmail.com (Geraldus)
Date: Wed, 02 Sep 2015 19:33:36 +0000
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <20150902192920.GA7423@casa.casa>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <20150902192920.GA7423@casa.casa>
Message-ID: <CAB2YT55SwWrRT2SD0yCaJWYM5qBfW0mn=S2fE6NUv9MiA48y6w@mail.gmail.com>

I'm missing this too.  GHC should be the right choice.

??, 3 ????. 2015 ?. ? 0:30, Francesco Ariis <fa-ml at ariis.it>:

> On Wed, Sep 02, 2015 at 09:44:21PM +0300, Kostiantyn Rybnikov wrote:
> > I think some flag, which would be turned on by default, which would
> > indicate to "recompile modules if they previously had warnings" would be
> > awesome to have.
> >
> > 1. would you like to have that flag?
> > 2. would you like it "on" by default?
> > 3. should ticket go into ghc or stack/cabal-install project?
> >
> > Thank you.
>
> I use often invoke ghc with `-Wall` and have experienced the same
> problem. I would like to have such a flag (off by default).
> I *think* the correct place where to implement this would be ghc.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/e1c6c900/attachment.html>

From rf at rufflewind.com  Wed Sep  2 22:42:06 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Wed, 2 Sep 2015 18:42:06 -0400
Subject: [Haskell-cafe] Foreign calls and periodic alarm signals
Message-ID: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>

TL;DR: Does 'foreign import safe' silence the periodic alarm signals?

I received a report on this rather strange bug in 'directory':

https://github.com/haskell/directory/issues/35#issuecomment-136890912

I've concluded based on the dtruss log that it's caused by the timer
signal that the GHC runtime emits.  Somewhere inside the guts of
'realpath' on Mac OS X, there is a function that does the moral
equivalent of:

    while (statfs64(?) && errno == EINTR);

On a slow filesystem like SSHFS, this can cause a permanent hang from
the barrage of signals.

The reporter found that using 'foreign import safe' mitigates the
issue.  What I'm curious mainly is that: is something that the GHC
runtime guarantees -- is using 'foreign import safe' assured to turn
off the periodic signals for that thread?

I tried reading this article [1], which seems to be the only
documentation I could find about this, and it didn't really go into
much depth about them.  (I also couldn't find any info about how
frequently they occur, on which threads they occur, or which specific
signal it uses.)

I'm also concerned whether there are other foreign functions out in
the wild that could suffer the same bug, but remain hidden because
they normally complete before the next alarm signal.

[1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals

From tkoster at gmail.com  Wed Sep  2 23:23:41 2015
From: tkoster at gmail.com (Thomas Koster)
Date: Thu, 3 Sep 2015 09:23:41 +1000
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
Message-ID: <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>

On 3 September 2015 at 04:44, Kostiantyn Rybnikov <k-bx at k-bx.com> wrote:
> There's a common situation I get into: I compile with "stack build" (or
> cabal build), get a big list of warnings, fix few of them, then I re-compile
> project, but a lot of warnings are gone now. The only option I'm left with
> is to use "-fforce-recomp".

If you're going to fix all the warnings anyway, why not just use -Werror?

--
Thomas Koster

From achudnov at gmail.com  Wed Sep  2 23:44:32 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Wed, 2 Sep 2015 19:44:32 -0400
Subject: [Haskell-cafe] Examples for Control.Lens.Plated?
Message-ID: <55E789E0.60107@gmail.com>

Hello Cafe,
I'm considering porting some of my code that uses uniplate to lens. But 
Control.Lens.Plated is giving me headaches. So I'm looking for remedy.

Has anyone used it and willing to share examples? I hope that seeing 
some of the combinators in action would help me understand the type 
signatures and documentation. What I'm particularly interested in is the 
following:
1) implementation of something like transformBi and rewriteBi using lens
2) usage of *On, *Off and *OnOff combinators (e.g., transformMOn, 
transformMOff, transformMOnOff). What I want to understand is the 
difference between the 3 variants. Also, what does it mean to "Transform 
every element in the tree in a region indicated by a supplied Traversal" 
and how exactly does the traversal define the region.
3) any recursive tree traversals/transformations using Plated that stop 
the recursion at a certain point (e.g., upon seeing a certain constructor)

I hope this isn't too vague, but, please, let me know if it is.

/Andrey

From donn at avvanta.com  Wed Sep  2 23:56:20 2015
From: donn at avvanta.com (Donn Cave)
Date: Wed,  2 Sep 2015 16:56:20 -0700 (PDT)
Subject: [Haskell-cafe] Foreign calls and periodic alarm signals
In-Reply-To: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>
References: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>
Message-ID: <20150902235620.7FFD7F3936@mail.avvanta.com>

quoth Phil Ruffwind <rf at rufflewind.com>

[... re SIGVTALRM from thread scheduling ...]

> The reporter found that using 'foreign import safe' mitigates the
> issue.  What I'm curious mainly is that: is something that the GHC
> runtime guarantees -- is using 'foreign import safe' assured to turn
> off the periodic signals for that thread?

Can't answer that, but I suppose I would recommend it anyway, because
unsafe foreign calls cause other OS threads to block in the runtime.
So any real I/O might as well be "safe".

To reliably avoid these signals, you can turn them off with the -V0
runtime flag.  For a UNIX shell example, GHCRTS=-V0 your-command-here.
You have to build it with the -rtsopts flag.

I suppose there are some consequences to doing that, but I've never
noticed anything and haven't heard of anyone else noticing anything.

> I'm also concerned whether there are other foreign functions out in
> the wild that could suffer the same bug, but remain hidden because
> they normally complete before the next alarm signal.

Sure are, though I don't know of any that have been identified so
directly as yours.  I mean it sounds like you know where and how it's
breaking.  Usually we just know something's dying on an interrupt and 
then think to try turning off the signal barrage.  It's interesting
that you're getting a stall instead, due to an EINTR loop.

	Donn

From allbery.b at gmail.com  Thu Sep  3 00:10:29 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 2 Sep 2015 20:10:29 -0400
Subject: [Haskell-cafe] Foreign calls and periodic alarm signals
In-Reply-To: <20150902235620.7FFD7F3936@mail.avvanta.com>
References: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>
 <20150902235620.7FFD7F3936@mail.avvanta.com>
Message-ID: <CAKFCL4Va5Y-XACW8za47B=R9ruf9Bq_c7brBO35qP+xrfEOF5Q@mail.gmail.com>

On Wed, Sep 2, 2015 at 7:56 PM, Donn Cave <donn at avvanta.com> wrote:

> Sure are, though I don't know of any that have been identified so
> directly as yours.  I mean it sounds like you know where and how it's
> breaking.  Usually we just know something's dying on an interrupt and
> then think to try turning off the signal barrage.  It's interesting
> that you're getting a stall instead, due to an EINTR loop.
>

network is moderately infamous for (formerly?) using unsafe calls that
block....

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/81905f60/attachment.html>

From capn.freako at gmail.com  Thu Sep  3 00:37:52 2015
From: capn.freako at gmail.com (David Banas)
Date: Wed, 2 Sep 2015 17:37:52 -0700
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
	version, ala stack?
Message-ID: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>

Hi all,

How do I direct cabal to use an alternative (i.e. - not my system?s default) version of ghc, which I?ve installed, via stack?

I tried this:

stack exec cabal install ...

but got this:

cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
Cabal. Use the flag --package-db to specify a package database (it can be used
multiple times).

Thanks,
-db

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150902/6ab94ba9/attachment.html>

From the.dead.shall.rise at gmail.com  Thu Sep  3 01:12:09 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 3 Sep 2015 03:12:09 +0200
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
 version, ala stack?
In-Reply-To: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
Message-ID: <CA+tcxkCDbeAWHKbXGFxq6pLs8pCjQqJ9i-F1b7B2xeEDfY15og@mail.gmail.com>

Hi,

On 3 September 2015 at 02:37, David Banas <capn.freako at gmail.com> wrote:
> Hi all,
>
> How do I direct cabal to use an alternative (i.e. - not my system?s default)
> version of ghc, which I?ve installed, via stack?


Try 'cabal install -w /path/to/ghc foo'.

From mantkiew at gsd.uwaterloo.ca  Thu Sep  3 01:31:01 2015
From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca)
Date: Wed, 02 Sep 2015 21:31:01 -0400
Subject: [Haskell-cafe] Examples for Control.Lens.Plated?
In-Reply-To: <55E789E0.60107@gmail.com>
References: <55E789E0.60107@gmail.com>
Message-ID: <20150903013101.5476436.38177.11574@gsd.uwaterloo.ca>

+1 I've been missing such examples for a long time too.?

Micha?

? Original Message ?
From: Andrey Chudnov
Sent: Wednesday, September 2, 2015 7:44 PM
To: haskell-cafe
Subject: [Haskell-cafe] Examples for Control.Lens.Plated?

Hello Cafe,
I'm considering porting some of my code that uses uniplate to lens. But 
Control.Lens.Plated is giving me headaches. So I'm looking for remedy.

Has anyone used it and willing to share examples? I hope that seeing 
some of the combinators in action would help me understand the type 
signatures and documentation. What I'm particularly interested in is the 
following:
1) implementation of something like transformBi and rewriteBi using lens
2) usage of *On, *Off and *OnOff combinators (e.g., transformMOn, 
transformMOff, transformMOnOff). What I want to understand is the 
difference between the 3 variants. Also, what does it mean to "Transform 
every element in the tree in a region indicated by a supplied Traversal" 
and how exactly does the traversal define the region.
3) any recursive tree traversals/transformations using Plated that stop 
the recursion at a certain point (e.g., upon seeing a certain constructor)

I hope this isn't too vague, but, please, let me know if it is.

/Andrey
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From alan.zimm at gmail.com  Thu Sep  3 01:42:57 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 3 Sep 2015 03:42:57 +0200
Subject: [Haskell-cafe] Private packages on hackage
Message-ID: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>

Hi all

I had a chat with Duncan Coutts of Well-Typed about the possibility of an
extension to hackage which would allow private packages to be uploaded and
managed by hackage, for a fee.

The idea is that it operates in a similar fashion to GitHub, where public
packages are free, but there is a monthly fee for hosting private packages.
This would give commercial organisations wanting to get started with
Haskell a simple way to host their packages, so that members of the
organisation could see the private and public packages when logged in, and
cabal install would work as expected with the superset.

Duncan is worried about the up-front effort required vs an uncertain return.

Personally I think that this could be a good way to fund the hackage
infrastructure.

So the question is, apart from me, would anyone be interested in such a
feature?

Regards
  Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/ac0cf7cc/attachment.html>

From michael at snoyman.com  Thu Sep  3 03:59:09 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 3 Sep 2015 06:59:09 +0300
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
 version, ala stack?
In-Reply-To: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
Message-ID: <CAKA2JgL-6VYGiCWdMfqD9UW=+KeZ2FHef=6amAyURcwyTr0jew@mail.gmail.com>

On Thu, Sep 3, 2015 at 3:37 AM, David Banas <capn.freako at gmail.com> wrote:

> Hi all,
>
> How do I direct cabal to use an alternative (i.e. - not my system?s
> default) version of ghc, which I?ve installed, via stack?
>
> I tried this:
>
> stack exec cabal install ...
>
>
> but got this:
>
> cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible
> with
> Cabal. Use the flag --package-db to specify a package database (it can be
> used
> multiple times).
>
>
> Thanks,
> -db
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
We have a flag to working better with cabal, you can try:

    stack exec --no-ghc-package-path -- cabal install

I'm under the impression that there are changes planned to cabal (possibly
already implemented but not released) that will allow it to function nicely
with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's
true.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/0b09c186/attachment.html>

From achudnov at gmail.com  Thu Sep  3 04:06:04 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Thu, 3 Sep 2015 00:06:04 -0400
Subject: [Haskell-cafe] Examples for Control.Lens.Plated?
In-Reply-To: <20150903013101.5476436.38177.11574@gsd.uwaterloo.ca>
References: <55E789E0.60107@gmail.com>
 <20150903013101.5476436.38177.11574@gsd.uwaterloo.ca>
Message-ID: <55E7C72C.1060703@gmail.com>

I thought I'd add an example of what I'm trying to do and what I think 
transformMOnOff might be very helpful with... that is, if I only knew 
how to use it. So suppose I have two mutrec data types,

 > data A = A [A] | B B | I Int
 > data B = B [A]

Suppose I want to write a function

 > incrementByNestingDepth :: A -> A

that would traverse the tree and increment all the I's by their nesting 
depth in B, e.g.

 > incrementByNestingDepth (A [I 1, I 3, B [ A [I 2], B [I 1]]]) = A [I 
1, I 3, B [A [I 3], B [I 3]]]

I could write that with just recursion on A and B, which could get 
tedious if I had several datatypes with 20 constructors each. Or I could 
use uniplate. But that's still quite tedious:

 > incrementByNestingDepth a = runState (incrementM a) 0
 > incrementM :: A -> State Int A
 > incrementM a = case a of
 >      I i -> liftM (A . (i +)) get
 >      B b->liftM B $ descendBiM incrementM b
 >      _  -> descendM incrementM a

The code isn't much smaller than for a handwritten traversal and you 
could imagine (or take my word for it) that one still doesn't see a lot 
of saved space using uniplate with more elaborate examples.

Now, don't get me wrong: I'm not saying uniplate is useless. In fact, 
it's one of the most useful libraries I've ever used. It's simple and 
does sheer magic more often than not.

However, for the sake of compositionality what (I think) one would like 
to do in this case is have two traversals: the outer which says "for 
every B, transform its A-children recursively like this" and the inner 
says "for every A, transform all of its children recursively, but until 
you see a B". You can't really do that with transform/rewrite in 
uniplate, so one has to fall back to descend which requires you to set 
up your recursion yourself.

The documentation in Control.Lens.Plated alludes that the traversal 
above might just be possible using transformOnOff, but, unfortunately, 
it does not go into any detail how exactly could one achieve that.

/Andrey

On 09/02/2015 09:31 PM, mantkiew at gsd.uwaterloo.ca wrote:
> +1 I've been missing such examples for a long time too.
>
> Micha?
>
>    Original Message
> From: Andrey Chudnov
> Sent: Wednesday, September 2, 2015 7:44 PM
> To: haskell-cafe
> Subject: [Haskell-cafe] Examples for Control.Lens.Plated?
>
> Hello Cafe,
> I'm considering porting some of my code that uses uniplate to lens. But
> Control.Lens.Plated is giving me headaches. So I'm looking for remedy.
>
> Has anyone used it and willing to share examples? I hope that seeing
> some of the combinators in action would help me understand the type
> signatures and documentation. What I'm particularly interested in is the
> following:
> 1) implementation of something like transformBi and rewriteBi using lens
> 2) usage of *On, *Off and *OnOff combinators (e.g., transformMOn,
> transformMOff, transformMOnOff). What I want to understand is the
> difference between the 3 variants. Also, what does it mean to "Transform
> every element in the tree in a region indicated by a supplied Traversal"
> and how exactly does the traversal define the region.
> 3) any recursive tree traversals/transformations using Plated that stop
> the recursion at a certain point (e.g., upon seeing a certain constructor)
>
> I hope this isn't too vague, but, please, let me know if it is.
>
> /Andrey
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From roma at ro-che.info  Thu Sep  3 04:44:17 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 3 Sep 2015 07:44:17 +0300
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
 version, ala stack?
In-Reply-To: <CA+tcxkCDbeAWHKbXGFxq6pLs8pCjQqJ9i-F1b7B2xeEDfY15og@mail.gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
 <CA+tcxkCDbeAWHKbXGFxq6pLs8pCjQqJ9i-F1b7B2xeEDfY15og@mail.gmail.com>
Message-ID: <55E7D021.1030107@ro-che.info>

On 03/09/15 04:12, Mikhail Glushenkov wrote:
> Hi,
> 
> On 3 September 2015 at 02:37, David Banas <capn.freako at gmail.com> wrote:
>> Hi all,
>>
>> How do I direct cabal to use an alternative (i.e. - not my system?s default)
>> version of ghc, which I?ve installed, via stack?
> 
> 
> Try 'cabal install -w /path/to/ghc foo'.

Or simply add the path to ghc to PATH, as in

PATH=$HOME/.stack/programs/x86_64-linux/ghc-$VERSION/bin:$PATH


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/537cc26a/attachment.sig>

From sean.leather at gmail.com  Thu Sep  3 05:49:29 2015
From: sean.leather at gmail.com (Sean Leather)
Date: Thu, 3 Sep 2015 07:49:29 +0200
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
Message-ID: <CACz_ru3Gy9NHweCVK7W+D7vE5Y9Jr1zKG=QOEFVTVDFcBba1rg@mail.gmail.com>

On Thu, Sep 3, 2015 at 3:42 AM, Alan & Kim Zimmerman wrote:

> I had a chat with Duncan Coutts of Well-Typed about the possibility of an
> extension to hackage which would allow private packages to be uploaded and
> managed by hackage, for a fee.
>
> The idea is that it operates in a similar fashion to GitHub, where public
> packages are free, but there is a monthly fee for hosting private packages.
> This would give commercial organisations wanting to get started with
> Haskell a simple way to host their packages, so that members of the
> organisation could see the private and public packages when logged in, and
> cabal install would work as expected with the superset.
>
> Duncan is worried about the up-front effort required vs an uncertain
> return.
>
> Personally I think that this could be a good way to fund the hackage
> infrastructure.
>
> So the question is, apart from me, would anyone be interested in such a
> feature?
>

There are several of us a bit to the north of you, Alan, that would fully
support this.

Regards,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/56c20c32/attachment.html>

From tomas.carnecky at gmail.com  Thu Sep  3 06:39:51 2015
From: tomas.carnecky at gmail.com (Tomas Carnecky)
Date: Thu, 03 Sep 2015 06:39:51 +0000
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CACz_ru3Gy9NHweCVK7W+D7vE5Y9Jr1zKG=QOEFVTVDFcBba1rg@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <CACz_ru3Gy9NHweCVK7W+D7vE5Y9Jr1zKG=QOEFVTVDFcBba1rg@mail.gmail.com>
Message-ID: <CAPabhsLxuJPHC7mqw4wXwrReVNfE4p0_BpgxEomN8b-Avmw4eA@mail.gmail.com>

On Thu, Sep 3, 2015 at 7:50 AM Sean Leather <sean.leather at gmail.com> wrote:

> On Thu, Sep 3, 2015 at 3:42 AM, Alan & Kim Zimmerman wrote:
>
>> I had a chat with Duncan Coutts of Well-Typed about the possibility of an
>> extension to hackage which would allow private packages to be uploaded and
>> managed by hackage, for a fee.
>>
>> The idea is that it operates in a similar fashion to GitHub, where public
>> packages are free, but there is a monthly fee for hosting private packages.
>> This would give commercial organisations wanting to get started with
>> Haskell a simple way to host their packages, so that members of the
>> organisation could see the private and public packages when logged in, and
>> cabal install would work as expected with the superset.
>>
>> Duncan is worried about the up-front effort required vs an uncertain
>> return.
>>
>> Personally I think that this could be a good way to fund the hackage
>> infrastructure.
>>
>> So the question is, apart from me, would anyone be interested in such a
>> feature?
>>
>
> There are several of us a bit to the north of you, Alan, that would fully
> support this.
>

How about teaching cabal how to fetch packages directly from SCM?
Organizations already have SCM systems set up, and the package metadata
(.cabal file) is already in there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/16cea56e/attachment.html>

From alan.zimm at gmail.com  Thu Sep  3 06:45:56 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 3 Sep 2015 08:45:56 +0200
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CAPabhsLxuJPHC7mqw4wXwrReVNfE4p0_BpgxEomN8b-Avmw4eA@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <CACz_ru3Gy9NHweCVK7W+D7vE5Y9Jr1zKG=QOEFVTVDFcBba1rg@mail.gmail.com>
 <CAPabhsLxuJPHC7mqw4wXwrReVNfE4p0_BpgxEomN8b-Avmw4eA@mail.gmail.com>
Message-ID: <CANma=H8ELqDkRSz5PbNOPnwYwGrLj71VQOqD7CKxAx9+_w9Bqg@mail.gmail.com>

It's as much about search functionality, on - line documentation and a
consistent location for the packages as it is about installing them.

Alan
On 02 Sep 2015 11:40 PM, "Tomas Carnecky" <tomas.carnecky at gmail.com> wrote:

> On Thu, Sep 3, 2015 at 7:50 AM Sean Leather <sean.leather at gmail.com>
> wrote:
>
>> On Thu, Sep 3, 2015 at 3:42 AM, Alan & Kim Zimmerman wrote:
>>
>>> I had a chat with Duncan Coutts of Well-Typed about the possibility of
>>> an extension to hackage which would allow private packages to be uploaded
>>> and managed by hackage, for a fee.
>>>
>>> The idea is that it operates in a similar fashion to GitHub, where
>>> public packages are free, but there is a monthly fee for hosting private
>>> packages. This would give commercial organisations wanting to get started
>>> with Haskell a simple way to host their packages, so that members of the
>>> organisation could see the private and public packages when logged in, and
>>> cabal install would work as expected with the superset.
>>>
>>> Duncan is worried about the up-front effort required vs an uncertain
>>> return.
>>>
>>> Personally I think that this could be a good way to fund the hackage
>>> infrastructure.
>>>
>>> So the question is, apart from me, would anyone be interested in such a
>>> feature?
>>>
>>
>> There are several of us a bit to the north of you, Alan, that would fully
>> support this.
>>
>
> How about teaching cabal how to fetch packages directly from SCM?
> Organizations already have SCM systems set up, and the package metadata
> (.cabal file) is already in there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/d1214259/attachment.html>

From roma at ro-che.info  Thu Sep  3 07:02:06 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 3 Sep 2015 10:02:06 +0300
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CAPabhsLxuJPHC7mqw4wXwrReVNfE4p0_BpgxEomN8b-Avmw4eA@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <CACz_ru3Gy9NHweCVK7W+D7vE5Y9Jr1zKG=QOEFVTVDFcBba1rg@mail.gmail.com>
 <CAPabhsLxuJPHC7mqw4wXwrReVNfE4p0_BpgxEomN8b-Avmw4eA@mail.gmail.com>
Message-ID: <55E7F06E.7080808@ro-che.info>

On 03/09/15 09:39, Tomas Carnecky wrote:

> How about teaching cabal how to fetch packages directly from SCM?
> Organizations already have SCM systems set up, and the package metadata
> (.cabal file) is already in there.

stack already does it iirc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/9d7966e6/attachment.sig>

From roma at ro-che.info  Thu Sep  3 07:42:32 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 3 Sep 2015 10:42:32 +0300
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
Message-ID: <55E7F9E8.6040107@ro-che.info>

On 03/09/15 04:42, Alan & Kim Zimmerman wrote:
> Hi all
> 
> I had a chat with Duncan Coutts of Well-Typed about the possibility of
> an extension to hackage which would allow private packages to be
> uploaded and managed by hackage, for a fee.
> 
> The idea is that it operates in a similar fashion to GitHub, where
> public packages are free, but there is a monthly fee for hosting private
> packages. This would give commercial organisations wanting to get
> started with Haskell a simple way to host their packages, so that
> members of the organisation could see the private and public packages
> when logged in, and cabal install would work as expected with the superset.
> 
> Duncan is worried about the up-front effort required vs an uncertain return.
> 
> Personally I think that this could be a good way to fund the hackage
> infrastructure.
> 
> So the question is, apart from me, would anyone be interested in such a
> feature?

This raises the question of who hackage belongs to.

Historically hackage has been a public service with no-one in particular
behind it. Well-Typed volunteered to work on it occasionally, but there
wasn't a sense of ownership or responsibility.
(At least that was how it looked to me.)

Such a service I wouldn't put my private code on.

Recently it seems like Well-Typed started to put more and more effort
into hackage. Perhaps the next logical step is to take formal ownership
of hackage (or make their own clone of hackage providing this feature);
then Alan's idea would make more sense.

For instance, I'd have less of a problem using a similar service from FP
Complete, because I know they are running it.

At Signal Vine, we've already developed the infrastructure around
hosting and building packages, but otherwise I would consider using such
a service depending on what features it provides and how well it fits
out process (and how much it costs, obviously). Bare hackage with
private packages wouldn't cut it; if it did, we'd just run our own
hackage server.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/823993a6/attachment.sig>

From gershomb at gmail.com  Thu Sep  3 10:30:27 2015
From: gershomb at gmail.com (Gershom B)
Date: Thu, 3 Sep 2015 03:30:27 -0700
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <55E7F9E8.6040107@ro-che.info>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <55E7F9E8.6040107@ro-che.info>
Message-ID: <etPan.55e82180.a4e361a.844e@mbp.local>

On September 3, 2015 at 12:42:48 AM, Roman Cheplyaka (roma at ro-che.info) wrote:

> This raises the question of who hackage belongs to.
>  
> Historically hackage has been a public service with no-one in particular
> behind it. Well-Typed volunteered to work on it occasionally, but there
> wasn't a sense of ownership or responsibility.
> (At least that was how it looked to me.)

This has not been true for a long time. Hackage 1.0 was maintained by?Ross Paterson for many years. It was first written by Lemmih in 2004 (http://marc.info/?l=haskell&m=120492314116236) and developed and maintained as a community project. Some of the people at well-typed who have worked on it, such as Duncan, were working on it well before ?well-typed? even existed.

After the formation of the haskell.org?committee and the consolidation of our infrastructure it became the responsibility of the haskell.org?committee, and of the infrastructure team.

As the current hackage homepage still notes, ?hackage 2.0? was funded in large part through support of the Industrial Haskell Group. Additionally, work took place through GSoC projects. More ongoing work has been accomplished through subsequent GSoCs as well, including this year.

Hackage remains maintained, as with other community infrastructure, by the haskell infrastructure administrative team, with ultimate responsibility resting with the haskell.org?committee.

That said, I personally have no opinion on such a service, but since I am at ICFP as is Alan, I look forward to discussing it in person :-)

Cheers,
Gershom

From capn.freako at gmail.com  Thu Sep  3 12:32:45 2015
From: capn.freako at gmail.com (David Banas)
Date: Thu, 3 Sep 2015 05:32:45 -0700
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
	version, ala stack?
In-Reply-To: <CAKA2JgL-6VYGiCWdMfqD9UW=+KeZ2FHef=6amAyURcwyTr0jew@mail.gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
 <CAKA2JgL-6VYGiCWdMfqD9UW=+KeZ2FHef=6amAyURcwyTr0jew@mail.gmail.com>
Message-ID: <0709F328-50B0-4600-A251-F2CEA63BB707@gmail.com>

Thanks to all, whom replied.

I found that a simple ?stack install ?? worked perfectly, as an alternative to ?cabal install ...". Stack seems to have honored all the ?cabal ?? things I did in setting up my sandbox, including all my ?cabal sandbox ?add-source ?? commands (5 in all). And, of course, it used the back-rev?d version of ghc I configured it (i.e. - stack) for.

That is SO neat that I can?t understand why it?s not a featured item in the Stack documentation.
Thanks, Stack crew!

-db

On Sep 2, 2015, at 8:59 PM, Michael Snoyman <michael at snoyman.com> wrote:

> 
> 
> On Thu, Sep 3, 2015 at 3:37 AM, David Banas <capn.freako at gmail.com> wrote:
> Hi all,
> 
> How do I direct cabal to use an alternative (i.e. - not my system?s default) version of ghc, which I?ve installed, via stack?
> 
> I tried this:
> 
> stack exec cabal install ...
> 
> but got this:
> 
> cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
> Cabal. Use the flag --package-db to specify a package database (it can be used
> multiple times).
> 
> Thanks,
> -db
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
> 
> We have a flag to working better with cabal, you can try:
> 
>     stack exec --no-ghc-package-path -- cabal install
> 
> I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true.
> 
> Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/0e5c0401/attachment.html>

From Andrew.Butterfield at scss.tcd.ie  Thu Sep  3 12:54:12 2015
From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield)
Date: Thu, 3 Sep 2015 13:54:12 +0100
Subject: [Haskell-cafe] platform 2014.2.0.0 for Windows
Message-ID: <DC45D6C0-E81E-4ACC-8B4C-5182C3876753@scss.tcd.ie>

Where do I download Haskell Platform 2014.2.0.0 for Windows?
 - the current (new?) Haskell Platform page doesn't link to old versions anymore

(I want to build wxHaskell 0.92, but I gather it doesn't build  with ghc 7.10 right now)


Andrew Butterfield
School of Computer Science & Statistics
Trinity College
Dublin 2, Ireland


From michael at snoyman.com  Thu Sep  3 13:25:45 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 3 Sep 2015 16:25:45 +0300
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
 version, ala stack?
In-Reply-To: <0709F328-50B0-4600-A251-F2CEA63BB707@gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
 <CAKA2JgL-6VYGiCWdMfqD9UW=+KeZ2FHef=6amAyURcwyTr0jew@mail.gmail.com>
 <0709F328-50B0-4600-A251-F2CEA63BB707@gmail.com>
Message-ID: <CAKA2JgLY6KNt34oh6xkvyCdq2Zt1fksc+TsUTigHt0egBzZ6fA@mail.gmail.com>

I'm glad it worked, but I don't think it's doing what you think it's doing.
stack intentionally ignores cabal sandbox settings and the like so that the
tools don't step on each others' toes. I'm not sure what --add-source you
were using, but it's very unlikely that stack picked it up.

I am now quite curious what the problem was and how stack ended up just
working for this.

On Thu, Sep 3, 2015 at 3:32 PM, David Banas <capn.freako at gmail.com> wrote:

> Thanks to all, whom replied.
>
> I found that a simple ?stack install ?? worked perfectly, as an
> alternative to ?cabal install ...". Stack seems to have honored all the
> ?cabal ?? things I did in setting up my sandbox, including all my ?cabal
> sandbox ?add-source ?? commands (5 in all). And, of course, it used the
> back-rev?d version of ghc I configured it (i.e. - stack) for.
>
> That is SO neat that I can?t understand why it?s not a featured item in
> the Stack documentation.
> Thanks, Stack crew!
>
> -db
>
> On Sep 2, 2015, at 8:59 PM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
>
> On Thu, Sep 3, 2015 at 3:37 AM, David Banas <capn.freako at gmail.com> wrote:
>
>> Hi all,
>>
>> How do I direct cabal to use an alternative (i.e. - not my system?s
>> default) version of ghc, which I?ve installed, via stack?
>>
>> I tried this:
>>
>> stack exec cabal install ...
>>
>>
>> but got this:
>>
>> cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible
>> with
>> Cabal. Use the flag --package-db to specify a package database (it can be
>> used
>> multiple times).
>>
>>
>> Thanks,
>> -db
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
> We have a flag to working better with cabal, you can try:
>
>     stack exec --no-ghc-package-path -- cabal install
>
> I'm under the impression that there are changes planned to cabal (possibly
> already implemented but not released) that will allow it to function nicely
> with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's
> true.
>
> Michael
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/0e72429c/attachment.html>

From capn.freako at gmail.com  Thu Sep  3 14:17:14 2015
From: capn.freako at gmail.com (David Banas)
Date: Thu, 3 Sep 2015 07:17:14 -0700
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
	version, ala stack?
In-Reply-To: <CAKA2JgLY6KNt34oh6xkvyCdq2Zt1fksc+TsUTigHt0egBzZ6fA@mail.gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
 <CAKA2JgL-6VYGiCWdMfqD9UW=+KeZ2FHef=6amAyURcwyTr0jew@mail.gmail.com>
 <0709F328-50B0-4600-A251-F2CEA63BB707@gmail.com>
 <CAKA2JgLY6KNt34oh6xkvyCdq2Zt1fksc+TsUTigHt0egBzZ6fA@mail.gmail.com>
Message-ID: <92C2C1B9-622F-4D15-BDA8-47F265DBC9C0@gmail.com>

Hmm?is it possible that the packages entries in my stack.yaml file:

flags: {}
packages:
- '.'
- circat/
- hermit/
- hermit/examples/HIW13/second/plugin/
- hermit/optimizations/pretty/hermit-pretty/
- hermit-extras/
- kure/
- lambda-ccc/
- netlist/netlist/
- netlist/netlist-to-verilog/
- netlist/netlist-to-vhdl/
- netlist/verilog/
extra-deps:
- applicative-numbers-0.1.3
- marked-pretty-0.1
- ty-0.1.5
- type-unary-0.2.19
resolver: lts-2.22

are what guided stack down the right path, re: mimicking the effect of my ?cabal sandbox ?add-source ?? commands?

And that the version constraints in the ?lts-2.22? cabal.config just happened to be what I needed for this project?

-db

On Sep 3, 2015, at 6:25 AM, Michael Snoyman <michael at snoyman.com> wrote:

> I'm glad it worked, but I don't think it's doing what you think it's doing. stack intentionally ignores cabal sandbox settings and the like so that the tools don't step on each others' toes. I'm not sure what --add-source you were using, but it's very unlikely that stack picked it up.
> 
> I am now quite curious what the problem was and how stack ended up just working for this.
> 
> On Thu, Sep 3, 2015 at 3:32 PM, David Banas <capn.freako at gmail.com> wrote:
> Thanks to all, whom replied.
> 
> I found that a simple ?stack install ?? worked perfectly, as an alternative to ?cabal install ...". Stack seems to have honored all the ?cabal ?? things I did in setting up my sandbox, including all my ?cabal sandbox ?add-source ?? commands (5 in all). And, of course, it used the back-rev?d version of ghc I configured it (i.e. - stack) for.
> 
> That is SO neat that I can?t understand why it?s not a featured item in the Stack documentation.
> Thanks, Stack crew!
> 
> -db
> 
> On Sep 2, 2015, at 8:59 PM, Michael Snoyman <michael at snoyman.com> wrote:
> 
>> 
>> 
>> On Thu, Sep 3, 2015 at 3:37 AM, David Banas <capn.freako at gmail.com> wrote:
>> Hi all,
>> 
>> How do I direct cabal to use an alternative (i.e. - not my system?s default) version of ghc, which I?ve installed, via stack?
>> 
>> I tried this:
>> 
>> stack exec cabal install ...
>> 
>> but got this:
>> 
>> cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
>> Cabal. Use the flag --package-db to specify a package database (it can be used
>> multiple times).
>> 
>> Thanks,
>> -db
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> 
>> 
>> We have a flag to working better with cabal, you can try:
>> 
>>     stack exec --no-ghc-package-path -- cabal install
>> 
>> I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true.
>> 
>> Michael
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/fb892ef0/attachment.html>

From michael at snoyman.com  Thu Sep  3 14:19:28 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 03 Sep 2015 14:19:28 +0000
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
 version, ala stack?
In-Reply-To: <92C2C1B9-622F-4D15-BDA8-47F265DBC9C0@gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
 <CAKA2JgL-6VYGiCWdMfqD9UW=+KeZ2FHef=6amAyURcwyTr0jew@mail.gmail.com>
 <0709F328-50B0-4600-A251-F2CEA63BB707@gmail.com>
 <CAKA2JgLY6KNt34oh6xkvyCdq2Zt1fksc+TsUTigHt0egBzZ6fA@mail.gmail.com>
 <92C2C1B9-622F-4D15-BDA8-47F265DBC9C0@gmail.com>
Message-ID: <CAKA2Jg+6YM3Yt0eKg36yy3Svd6jHoYFnt0D=bTHRnuP9s22_Rg@mail.gmail.com>

Yup, that would do it.

On Thu, Sep 3, 2015, 5:17 PM David Banas <capn.freako at gmail.com> wrote:

> Hmm?is it possible that the *packages* entries in my *stack.yaml *file:
>
> flags: {}
> packages:
> - '.'
> - circat/
> - hermit/
> - hermit/examples/HIW13/second/plugin/
> - hermit/optimizations/pretty/hermit-pretty/
> - hermit-extras/
> - kure/
> - lambda-ccc/
> - netlist/netlist/
> - netlist/netlist-to-verilog/
> - netlist/netlist-to-vhdl/
> - netlist/verilog/
> extra-deps:
> - applicative-numbers-0.1.3
> - marked-pretty-0.1
> - ty-0.1.5
> - type-unary-0.2.19
> resolver: lts-2.22
>
>
> are what guided stack down the right path, re: mimicking the effect of my
> ?cabal sandbox ?add-source ?? commands?
>
> And that the version constraints in the ?lts-2.22? *cabal.config* just
> happened to be what I needed for this project?
>
> -db
>
> On Sep 3, 2015, at 6:25 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
> I'm glad it worked, but I don't think it's doing what you think it's
> doing. stack intentionally ignores cabal sandbox settings and the like so
> that the tools don't step on each others' toes. I'm not sure what
> --add-source you were using, but it's very unlikely that stack picked it up.
>
> I am now quite curious what the problem was and how stack ended up just
> working for this.
>
> On Thu, Sep 3, 2015 at 3:32 PM, David Banas <capn.freako at gmail.com> wrote:
>
>> Thanks to all, whom replied.
>>
>> I found that a simple ?stack install ?? worked perfectly, as an
>> alternative to ?cabal install ...". Stack seems to have honored all the
>> ?cabal ?? things I did in setting up my sandbox, including all my ?cabal
>> sandbox ?add-source ?? commands (5 in all). And, of course, it used the
>> back-rev?d version of ghc I configured it (i.e. - stack) for.
>>
>> That is SO neat that I can?t understand why it?s not a featured item in
>> the Stack documentation.
>> Thanks, Stack crew!
>>
>> -db
>>
>> On Sep 2, 2015, at 8:59 PM, Michael Snoyman <michael at snoyman.com> wrote:
>>
>>
>>
>> On Thu, Sep 3, 2015 at 3:37 AM, David Banas <capn.freako at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> How do I direct cabal to use an alternative (i.e. - not my system?s
>>> default) version of ghc, which I?ve installed, via stack?
>>>
>>> I tried this:
>>>
>>> stack exec cabal install ...
>>>
>>>
>>> but got this:
>>>
>>> cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is
>>> incompatible with
>>> Cabal. Use the flag --package-db to specify a package database (it can
>>> be used
>>> multiple times).
>>>
>>>
>>> Thanks,
>>> -db
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>> We have a flag to working better with cabal, you can try:
>>
>>     stack exec --no-ghc-package-path -- cabal install
>>
>> I'm under the impression that there are changes planned to cabal
>> (possibly already implemented but not released) that will allow it to
>> function nicely with the GHC_PACKAGE_PATH environment variable, but I'm
>> uncertain if that's true.
>>
>> Michael
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/a6fcb7e3/attachment.html>

From hjgtuyl at chello.nl  Thu Sep  3 14:23:44 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Thu, 03 Sep 2015 16:23:44 +0200
Subject: [Haskell-cafe] platform 2014.2.0.0 for Windows
In-Reply-To: <DC45D6C0-E81E-4ACC-8B4C-5182C3876753@scss.tcd.ie>
References: <DC45D6C0-E81E-4ACC-8B4C-5182C3876753@scss.tcd.ie>
Message-ID: <op.x4d4xuzjpz0j5l@alquantor>

On Thu, 03 Sep 2015 14:54:12 +0200, Andrew Butterfield  
<Andrew.Butterfield at scss.tcd.ie> wrote:

> Where do I download Haskell Platform 2014.2.0.0 for Windows?
>  - the current (new?) Haskell Platform page doesn't link to old versions  
> anymore
>
> (I want to build wxHaskell 0.92, but I gather it doesn't build  with ghc  
> 7.10 right now)

wxHaskell 0.92 does compile with GHC 7.10, but Windows requires a things  
to be exactly right[0], which messages do you get when you try to install  
it?

Regards,
Henk-Jan van Tuyl

[0] https://wiki.haskell.org/WxHaskell/Windows


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From hesselink at gmail.com  Thu Sep  3 14:17:18 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 3 Sep 2015 16:17:18 +0200
Subject: [Haskell-cafe] How to direct cabal to use an alternative ghc
 version, ala stack?
In-Reply-To: <CAKA2JgLY6KNt34oh6xkvyCdq2Zt1fksc+TsUTigHt0egBzZ6fA@mail.gmail.com>
References: <F519DE7A-9498-482A-8609-32A4893FC1D9@gmail.com>
 <CAKA2JgL-6VYGiCWdMfqD9UW=+KeZ2FHef=6amAyURcwyTr0jew@mail.gmail.com>
 <0709F328-50B0-4600-A251-F2CEA63BB707@gmail.com>
 <CAKA2JgLY6KNt34oh6xkvyCdq2Zt1fksc+TsUTigHt0egBzZ6fA@mail.gmail.com>
Message-ID: <CAPeieQHtqQAy_+2TS1k5TAUq+=REg0N3wb4_E0SwPQ_4N8fjFg@mail.gmail.com>

If I had to guess, I'd say there's a directory structure like:

/project
  /foo
  /bar
  /baz

And stack found all the packages in those subdirs. It just happened to
be that those were the exact ones that were add-source'd.

But this is just a guess, of course.

Erik

On 3 September 2015 at 15:25, Michael Snoyman <michael at snoyman.com> wrote:
> I'm glad it worked, but I don't think it's doing what you think it's doing.
> stack intentionally ignores cabal sandbox settings and the like so that the
> tools don't step on each others' toes. I'm not sure what --add-source you
> were using, but it's very unlikely that stack picked it up.
>
> I am now quite curious what the problem was and how stack ended up just
> working for this.
>
> On Thu, Sep 3, 2015 at 3:32 PM, David Banas <capn.freako at gmail.com> wrote:
>>
>> Thanks to all, whom replied.
>>
>> I found that a simple ?stack install ?? worked perfectly, as an
>> alternative to ?cabal install ...". Stack seems to have honored all the
>> ?cabal ?? things I did in setting up my sandbox, including all my ?cabal
>> sandbox ?add-source ?? commands (5 in all). And, of course, it used the
>> back-rev?d version of ghc I configured it (i.e. - stack) for.
>>
>> That is SO neat that I can?t understand why it?s not a featured item in
>> the Stack documentation.
>> Thanks, Stack crew!
>>
>> -db
>>
>> On Sep 2, 2015, at 8:59 PM, Michael Snoyman <michael at snoyman.com> wrote:
>>
>>
>>
>> On Thu, Sep 3, 2015 at 3:37 AM, David Banas <capn.freako at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> How do I direct cabal to use an alternative (i.e. - not my system?s
>>> default) version of ghc, which I?ve installed, via stack?
>>>
>>> I tried this:
>>>
>>> stack exec cabal install ...
>>>
>>>
>>> but got this:
>>>
>>> cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible
>>> with
>>> Cabal. Use the flag --package-db to specify a package database (it can be
>>> used
>>> multiple times).
>>>
>>>
>>> Thanks,
>>> -db
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>> We have a flag to working better with cabal, you can try:
>>
>>     stack exec --no-ghc-package-path -- cabal install
>>
>> I'm under the impression that there are changes planned to cabal (possibly
>> already implemented but not released) that will allow it to function nicely
>> with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's
>> true.
>>
>> Michael
>>
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From alan.zimm at gmail.com  Thu Sep  3 15:04:51 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 3 Sep 2015 17:04:51 +0200
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <55E7F9E8.6040107@ro-che.info>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <55E7F9E8.6040107@ro-che.info>
Message-ID: <CANma=H9i337gnJgvTAuRTMUQgxgw6iWyQfMZg5B4JWDN=VqLYg@mail.gmail.com>

> At Signal Vine, we've already developed the infrastructure around
> hosting and building packages, but otherwise I would consider using such
> a service depending on what features it provides and how well it fits
> out process (and how much it costs, obviously). Bare hackage with
> private packages wouldn't cut it; if it did, we'd just run our own
> hackage server.
>
>
My thinking actually started with possibly running our own hackage server,
but then you have to allocate a machine and take time/skills to administer
it. So if a service like this is available at a similar or lower cost it
starts to make sense.

It also lowers the bar for commercial take-up, by sending a signal that
commercial users are supported, and allowing "toe-in-the water" commercial
projects at low upfront cost.




> Roman
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/b6db693a/attachment.html>

From acfoltzer at gmail.com  Thu Sep  3 18:10:46 2015
From: acfoltzer at gmail.com (Adam Foltzer)
Date: Thu, 3 Sep 2015 11:10:46 -0700
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CANma=H9i337gnJgvTAuRTMUQgxgw6iWyQfMZg5B4JWDN=VqLYg@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <55E7F9E8.6040107@ro-che.info>
 <CANma=H9i337gnJgvTAuRTMUQgxgw6iWyQfMZg5B4JWDN=VqLYg@mail.gmail.com>
Message-ID: <CAPorAaFSEa8AG0y9-Fg6RXMfqOCmCuN3zJKREZj+HLB53THZcw@mail.gmail.com>

Perhaps we can discuss this further in person during the Symposium, but at
first glance I am strongly opposed to adding this sort of paid service to
Hackage under the Haskell.org umbrella.

I share Duncan's doubts that the amount of money brought in would offset
the amount of time spent implementing, maintaining, and supporting even
just this feature, not to mention the fact that this would surely
complicate development and maintenance of the open-source side of Hackage.

This approach also exacerbates the wart of cabal-install's interdependency
with hackage.haskell.org. I would much prefer to see a commercial vendor,
perhaps Well-Typed or FPComplete, able to spin up proprietary Hackages as a
service for commercial users, and for those Hackages to integrate well with
hackage.haskell.org.

That there is enthusiasm for this idea shows that there might be a viable
commercial idea here, but Haskell.org is not the home for it.

Adam

On Thu, Sep 3, 2015 at 8:04 AM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

>
> At Signal Vine, we've already developed the infrastructure around
>> hosting and building packages, but otherwise I would consider using such
>> a service depending on what features it provides and how well it fits
>> out process (and how much it costs, obviously). Bare hackage with
>> private packages wouldn't cut it; if it did, we'd just run our own
>> hackage server.
>>
>>
> My thinking actually started with possibly running our own hackage server,
> but then you have to allocate a machine and take time/skills to administer
> it. So if a service like this is available at a similar or lower cost it
> starts to make sense.
>
> It also lowers the bar for commercial take-up, by sending a signal that
> commercial users are supported, and allowing "toe-in-the water" commercial
> projects at low upfront cost.
>
>
>
>
>> Roman
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/4b69d2f5/attachment.html>

From allbery.b at gmail.com  Thu Sep  3 18:20:43 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 3 Sep 2015 14:20:43 -0400
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CAPorAaFSEa8AG0y9-Fg6RXMfqOCmCuN3zJKREZj+HLB53THZcw@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <55E7F9E8.6040107@ro-che.info>
 <CANma=H9i337gnJgvTAuRTMUQgxgw6iWyQfMZg5B4JWDN=VqLYg@mail.gmail.com>
 <CAPorAaFSEa8AG0y9-Fg6RXMfqOCmCuN3zJKREZj+HLB53THZcw@mail.gmail.com>
Message-ID: <CAKFCL4UNQC-_bH6SrfHM6t1hrn4mPvcou6NGa2+5nOq4ipdyoQ@mail.gmail.com>

On Thu, Sep 3, 2015 at 2:10 PM, Adam Foltzer <acfoltzer at gmail.com> wrote:

> This approach also exacerbates the wart of cabal-install's interdependency
> with hackage.haskell.org
>
> . I would much prefer to see a commercial vendor, perhaps Well-Typed or
> FPComplete, able to spin up proprietary Hackages as a service for
> commercial users, and for those Hackages to integrate well with
> hackage.haskell.org
>
> .
>

I can very well imagine commercial users not wanting to use a repo
owned/run by what might be a competitor.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/fd8c1568/attachment.html>

From alan.zimm at gmail.com  Thu Sep  3 18:31:51 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 3 Sep 2015 20:31:51 +0200
Subject: [Haskell-cafe] Private packages on hackage
In-Reply-To: <CAKFCL4UNQC-_bH6SrfHM6t1hrn4mPvcou6NGa2+5nOq4ipdyoQ@mail.gmail.com>
References: <CANma=H-VpnmZXn0AYXAgF7V50r7YLeo3B-3-T8dViEMn=VTfTA@mail.gmail.com>
 <55E7F9E8.6040107@ro-che.info>
 <CANma=H9i337gnJgvTAuRTMUQgxgw6iWyQfMZg5B4JWDN=VqLYg@mail.gmail.com>
 <CAPorAaFSEa8AG0y9-Fg6RXMfqOCmCuN3zJKREZj+HLB53THZcw@mail.gmail.com>
 <CAKFCL4UNQC-_bH6SrfHM6t1hrn4mPvcou6NGa2+5nOq4ipdyoQ@mail.gmail.com>
Message-ID: <CANma=H-d30p=Ma4rssUfwMjUTfMYpoyGne65ZWpvk3bjMwkk2Q@mail.gmail.com>

>>
>> . I would much prefer to see a commercial vendor, perhaps Well-Typed or
FPComplete, able to spin up proprietary Hackages as a service for
commercial users, and for those Hackages to integrate well with
hackage.haskell.org
>>
>> .
>
>
> I can very well imagine commercial users not wanting to use a repo
owned/run by what might be a competitor.
>

I think there are different kinds of commercial users, some of us just want
to use it for internal projects so there is no conflict.

In terms of distracting from the core mission of haskell.org, I can
understand the viewpoint. Personally I do not mind who provides such a
service so long as it plays well with hackage. I wanted to start the
discussion wrt haskell.org so it can go forward in a neutral way.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150903/856e50fa/attachment.html>

From hamish.k.mackenzie at gmail.com  Thu Sep  3 21:32:42 2015
From: hamish.k.mackenzie at gmail.com (Hamish Mackenzie)
Date: Thu, 3 Sep 2015 14:32:42 -0700
Subject: [Haskell-cafe] Foreign calls and periodic alarm signals
In-Reply-To: <20150902235620.7FFD7F3936@mail.avvanta.com>
References: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>
 <20150902235620.7FFD7F3936@mail.avvanta.com>
Message-ID: <ABEAC5B4-195F-45DD-80B8-BEE768C41087@gmail.com>


> On 2 Sep 2015, at 16:56, Donn Cave <donn at avvanta.com> wrote:
> 
> To reliably avoid these signals, you can turn them off with the -V0
> runtime flag.  For a UNIX shell example, GHCRTS=-V0 your-command-here.
> You have to build it with the -rtsopts flag.

That does seem to have fixed it for me, thanks.

Hamish

From marlowsd at gmail.com  Thu Sep  3 22:12:07 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 3 Sep 2015 15:12:07 -0700
Subject: [Haskell-cafe] Foreign calls and periodic alarm signals
In-Reply-To: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>
References: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>
Message-ID: <55E8C5B7.9030309@gmail.com>

On 02/09/2015 15:42, Phil Ruffwind wrote:
> TL;DR: Does 'foreign import safe' silence the periodic alarm signals?

No it doesn't.  Perhaps the fact that a safe FFI call may create another 
worker thread means that the timer signal has gone to the other thread 
and didn't interrupt the thread making the statfs64() call.

There's pthread_setmask() that could help, but it's pretty difficult to 
do this in a consistent way because we'd have to pthread_setmask() every 
thread that runs Haskell code, including calls from outside.  I'm not 
sure yet what the right solution is, but a good start would be to open a 
ticket.

Cheers
Simon

> I received a report on this rather strange bug in 'directory':
>
> https://github.com/haskell/directory/issues/35#issuecomment-136890912
>
> I've concluded based on the dtruss log that it's caused by the timer
> signal that the GHC runtime emits.  Somewhere inside the guts of
> 'realpath' on Mac OS X, there is a function that does the moral
> equivalent of:
>
>      while (statfs64(?) && errno == EINTR);
>
> On a slow filesystem like SSHFS, this can cause a permanent hang from
> the barrage of signals.
>
> The reporter found that using 'foreign import safe' mitigates the
> issue.  What I'm curious mainly is that: is something that the GHC
> runtime guarantees -- is using 'foreign import safe' assured to turn
> off the periodic signals for that thread?
>
> I tried reading this article [1], which seems to be the only
> documentation I could find about this, and it didn't really go into
> much depth about them.  (I also couldn't find any info about how
> frequently they occur, on which threads they occur, or which specific
> signal it uses.)
>
> I'm also concerned whether there are other foreign functions out in
> the wild that could suffer the same bug, but remain hidden because
> they normally complete before the next alarm signal.
>
> [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From rf at rufflewind.com  Fri Sep  4 07:52:33 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Fri, 4 Sep 2015 03:52:33 -0400
Subject: [Haskell-cafe] Foreign calls and periodic alarm signals
In-Reply-To: <55E8C5B7.9030309@gmail.com>
References: <CADb8sTO5ueWJ=1NuzR8x7d8H0yfm=vQE2zCDggq1v3X63qke8g@mail.gmail.com>
 <55E8C5B7.9030309@gmail.com>
Message-ID: <CADb8sTOGAAJ0SSiqjAORcgxtb2ebqmoAESd5HS3qND7gj98mDQ@mail.gmail.com>

> a good start would be to open a ticket.

Okay, done: https://ghc.haskell.org/trac/ghc/ticket/10840

From lanablack at amok.cc  Fri Sep  4 12:26:20 2015
From: lanablack at amok.cc (Lana Black)
Date: Fri, 4 Sep 2015 12:26:20 +0000
Subject: [Haskell-cafe] Problem with lifted-async
Message-ID: <20150904122620.GA2088@rhea>

Hello,

I'm writing a thread supervisor that allows implicitly passing some
monadic context (e.g. ReaderT) using MonadBaseControl from
monad-control. The problem is that I don't know how to tackle this
error.

GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( ex.hs, interpreted )

ex.hs:20:20:
    Couldn't match type ?StM t a0? with ?StM t a?
    NB: ?StM? is a type function, and may not be injective
    The type variable ?a0? is ambiguous
    Expected type: Async (StM t a0)
      Actual type: Async (StM t a)
    Relevant bindings include
      as :: Async (StM t a) (bound at ex.hs:19:30)
      t :: Task t a (bound at ex.hs:19:28)
      td :: TaskDescriptor t (bound at ex.hs:19:10)
      pollTask :: TaskDescriptor t
                  -> TaskDescriptor t -> t (TaskDescriptor t)
        (bound at ex.hs:19:1)
    In the first argument of ?poll?, namely ?as?
    In a stmt of a 'do' block: st <- poll as
Failed, modules loaded: none.


This minimal code snippet would be

{-# LANGUAGE ExistentialQuantification  #-}
{-# LANGUAGE FlexibleContexts           #-}

import Control.Concurrent.Async.Lifted (Async,async,asyncBound,poll,cancel)
import Control.Monad.Trans.Control (MonadBaseControl,StM)

data Task m a = Task {
    taskVal   :: m a
}

data TaskDescriptor m = forall a. TaskDescriptor {
    task        :: Task m a,
    asyncThread :: Async (StM m a)
}

runTask :: forall a m. (MonadBaseControl IO m) => Task m a -> m (TaskDescriptor m)
runTask = undefined

pollTask td(TaskDescriptor t as) = do
        st <- poll as
        case st of
            Nothing -> pure td
            Just r -> runTask t

main = undefined



StM is a type from MonadBaseControl typeclass, the definition is

class MonadBase b m => MonadBaseControl b m | m -> b where
    type StM m a :: *
    liftBaseWith :: (RunInBase m b -> b a) -> m a
    restoreM :: StM m a -> m a

type RunInBase m b = forall a. m a -> b (StM m a)

I stripped the comments, the full version is here
https://hackage.haskell.org/package/monad-control-1.0.0.4/docs/src/Control-Monad-Trans-Control.html#MonadBaseControl

From sven.bartscher at weltraumschlangen.de  Fri Sep  4 13:13:44 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Fri, 4 Sep 2015 15:13:44 +0200
Subject: [Haskell-cafe] Physics engine for Haskell
Message-ID: <20150904151344.38f12fa7@sven.bartscher>

Greetings,

I'm looking for a game physics engine for Haskell. As Bullet is widely
used in this field, I went to use the Haskell Bullet binding, but had
to find, that it is very inconvenient to use, because of things like
making optional parameters necessary in the binding.

Is there any higher level binding to Bullet or some other Physics
library that is more convenient to use on Haskell?

Regards
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/d7177615/attachment.sig>

From manny at fpcomplete.com  Fri Sep  4 13:48:38 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Fri, 4 Sep 2015 06:48:38 -0700
Subject: [Haskell-cafe] ANN: stack-0.1.4.0 (and 0.1.4.1)
Message-ID: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>

See README <https://github.com/commercialhaskell/stack#how-to-install> for
installation and upgrade instructions.

Note: while stack-0.1.4.1 is on Hackage, the only change is to a comment so
that stack?s haddocks build. Therefore, no new binaries were generated.
Functionally, v0.1.4.0 is identical to v0.1.4.1.

Note: we have stopped uploading new versions to the Fedora 20 repository,
since that version of Fedora has reached end of life
<https://fedoraproject.org/wiki/End_of_life>. If you are using Fedora 20,
use stack upgrade or download the general Linux binary
<https://github.com/commercialhaskell/stack/wiki/Downloads#linux>.

Major changes:

   - You now have more control over how GHC versions are matched, e.g. ?use
   exactly this version,? ?use the specified minor version, but allow
   patches,? or ?use the given minor version or any later minor in the given
   major release.? The default has switched from allowing newer later minor
   versions to a specific minor version allowing patches. For more
   information, see #736
   <https://github.com/commercialhaskell/stack/issues/736> and #784
   <https://github.com/commercialhaskell/stack/pull/784>.
   - Support added for compiling with GHCJS
   - stack can now reuse prebuilt binaries between snapshots. That means
   that, if you build package foo in LTS-3.1, that binary version can be
   reused in LTS-3.2, assuming it uses the same dependencies and flags. #878
   <https://github.com/commercialhaskell/stack/issues/878>

Other enhancements:

   - Added the --docker-env argument, to set environment variables in
   Docker container.
   - Set locale environment variables to UTF-8 encoding for builds to avoid
   ?commitBuffer: invalid argument? errors from GHC #793
   <https://github.com/commercialhaskell/stack/issues/793>
   - Enable translitation for encoding on stdout and stderr #824
   <https://github.com/commercialhaskell/stack/issues/824>
   - By default, stack upgrade automatically installs GHC as necessary #797
   <https://github.com/commercialhaskell/stack/issues/797>
   - Added the ghc-options field to stack.yaml #796
   <https://github.com/commercialhaskell/stack/issues/796>
   - Added the extra-path field to stack.yaml
   - Code page changes on Windows only apply to the build command (and its
   synonyms), and can be controlled via a command line flag (still defaults to
   on) #757 <https://github.com/commercialhaskell/stack/issues/757>
   - Implicitly add packages to extra-deps when a flag for them is set #807
   <https://github.com/commercialhaskell/stack/issues/807>
   - Use a precompiled Setup.hs for simple build types #801
   <https://github.com/commercialhaskell/stack/issues/801>
   - Set ?enable-tests and ?enable-benchmarks optimistically #805
   <https://github.com/commercialhaskell/stack/issues/805>
   - --only-configure option added #820
   <https://github.com/commercialhaskell/stack/issues/820>
   - Check for duplicate local package names
   - Stop nagging people that call stack test #845
   <https://github.com/commercialhaskell/stack/issues/845>
   - --file-watch will ignore files that are in your VCS boring/ignore
   files #703 <https://github.com/commercialhaskell/stack/issues/703>
   - Add --numeric-version option

Bug fixes:

   - stack init --solver fails if GHC_PACKAGE_PATH is present #860
   <https://github.com/commercialhaskell/stack/issues/860>
   - stack solver and stack init --solver check for test suite and
   benchmark dependencies #862
   <https://github.com/commercialhaskell/stack/issues/862>
   - More intelligent logic for setting UTF-8 locale environment variables
   #856 <https://github.com/commercialhaskell/stack/issues/856>
   - Create missing directories for stack sdist
   - Don?t ignore .cabal files with extra periods #895
   <https://github.com/commercialhaskell/stack/issues/895>
   - Deprecate unused --optimizations flag
   - Truncated output on slow terminals #413
   <https://github.com/commercialhaskell/stack/issues/413>

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/ff7e49a8/attachment.html>

From simon at joyful.com  Fri Sep  4 14:12:08 2015
From: simon at joyful.com (Simon Michael)
Date: Fri, 4 Sep 2015 07:12:08 -0700
Subject: [Haskell-cafe] ANN: stack-0.1.4.0 (and 0.1.4.1)
In-Reply-To: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
References: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
Message-ID: <1DA74D2A-C2AA-462B-876F-22A1D1E6E232@joyful.com>

Hurrah! Thank you stack devs.

From adam at bergmark.nl  Fri Sep  4 17:35:04 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Fri, 4 Sep 2015 19:35:04 +0200
Subject: [Haskell-cafe] ANN: stack-0.1.4.0 (and 0.1.4.1)
In-Reply-To: <1DA74D2A-C2AA-462B-876F-22A1D1E6E232@joyful.com>
References: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
 <1DA74D2A-C2AA-462B-876F-22A1D1E6E232@joyful.com>
Message-ID: <CACnqJZZyfGga6wVUA+azYYEVj4jWzGxJV2gA5PPDZfK0P6bmrw@mail.gmail.com>

> stack can now reuse prebuilt binaries between snapshots.

This sounds amazing!

Thanks everyone,
Adam


On Fri, Sep 4, 2015 at 4:12 PM, Simon Michael <simon at joyful.com> wrote:

> Hurrah! Thank you stack devs.
>
> --
> You received this message because you are subscribed to the Google Groups
> "haskell-stack" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-stack+unsubscribe at googlegroups.com.
> To post to this group, send email to haskell-stack at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-stack/1DA74D2A-C2AA-462B-876F-22A1D1E6E232%40joyful.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/69fce5b9/attachment.html>

From mantkiew at gsd.uwaterloo.ca  Fri Sep  4 17:41:51 2015
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Fri, 4 Sep 2015 13:41:51 -0400
Subject: [Haskell-cafe] ANN: stack-0.1.4.0 (and 0.1.4.1)
In-Reply-To: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
References: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
Message-ID: <CAGW9QSxpWV0ymoMVy-SWLv=Ndp465zkkL0nsQ5Y8fUJH=D1mog@mail.gmail.com>

what a great release! Esp. the reuse of binaries between snapshots!


>    - Support added for compiling with GHCJS
>
> I presume that stack does not assist in installing GHCJS itself as it does
for ghc. Are there any plans of improving the ghcjs situation? What are the
current blockers?

Thanks,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/e2bd6139/attachment.html>

From hjgtuyl at chello.nl  Fri Sep  4 17:42:01 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Fri, 04 Sep 2015 19:42:01 +0200
Subject: [Haskell-cafe] Physics engine for Haskell
In-Reply-To: <20150904151344.38f12fa7@sven.bartscher>
References: <20150904151344.38f12fa7@sven.bartscher>
Message-ID: <op.x4f8sbktpz0j5l@alquantor>

On Fri, 04 Sep 2015 15:13:44 +0200, Sven Bartscher  
<sven.bartscher at weltraumschlangen.de> wrote:

> Greetings,
>
> I'm looking for a game physics engine for Haskell. As Bullet is widely
> used in this field, I went to use the Haskell Bullet binding, but had
> to find, that it is very inconvenient to use, because of things like
> making optional parameters necessary in the binding.
>
> Is there any higher level binding to Bullet or some other Physics
> library that is more convenient to use on Haskell?
>
> Regards
> Sven

See:
   https://wiki.haskell.org/Applications_and_libraries/Games#Game_Engines_and_Libraries
I don't have experience with these packages, so I don't know how  
convenient they are.

Regards,
Henk-Jan van Tuyl


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From mantkiew at gsd.uwaterloo.ca  Fri Sep  4 18:10:24 2015
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Fri, 4 Sep 2015 14:10:24 -0400
Subject: [Haskell-cafe] ANN: stack-0.1.4.0 (and 0.1.4.1)
In-Reply-To: <CAGW9QSxpWV0ymoMVy-SWLv=Ndp465zkkL0nsQ5Y8fUJH=D1mog@mail.gmail.com>
References: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
 <CAGW9QSxpWV0ymoMVy-SWLv=Ndp465zkkL0nsQ5Y8fUJH=D1mog@mail.gmail.com>
Message-ID: <CAGW9QSwdVNQWQ2DMiw2RPGXZti5NDsLoWbOK++XtHQ50thj95g@mail.gmail.com>

I'd like to post results of my small experiment to evaluate how awesome the
reuse of binaries between snapshots is.

I did the following:

1. Clean the C:\Users\<username>\AppData\Roaming\stack
2. Build my project for LTS-3.3
- 6 minutes
3. Switch to LTS-3.4 and build
- 20 seconds!

The reason? Here it is:

cmdargs-0.10.13: copying precompiled package
dlist-0.7.1.2: copying precompiled package
executable-path-0.0.3: copying precompiled package
nats-1: copying precompiled package
mtl-2.2.1: copying precompiled package
network-2.6.2.1: copying precompiled package
old-locale-1.0.0.7: copying precompiled package
base-orphans-0.4.4: copying precompiled package
parallel-3.2.0.6: copying precompiled package
prelude-extras-0.4: copying precompiled package
primitive-0.6: copying precompiled package
reflection-2: copying precompiled package
mtl-compat-0.2.1.3: copying precompiled package
split-0.2.2: copying precompiled package
old-time-1.1.0.3: copying precompiled package
stm-2.4.4: copying precompiled package
syb-0.5.1: copying precompiled package
tagged-0.8.1: copying precompiled package
text-1.2.1.3: copying precompiled package
transformers-compat-0.4.0.4: copying precompiled package
utf8-string-1.0.1.1: copying precompiled package
vector-0.10.12.3: copying precompiled package
StateVar-1.1.0.1: copying precompiled package
blaze-builder-0.4.0.1: copying precompiled package
hashable-1.2.3.3: copying precompiled package
parsec-3.1.9: copying precompiled package
distributive-0.4.4: copying precompiled package
exceptions-0.8.0.2: copying precompiled package
string-conversions-0.4: copying precompiled package
blaze-textual-0.2.1.0: copying precompiled package
unordered-containers-0.2.5.1: copying precompiled package
scientific-0.3.3.8: copying precompiled package
network-uri-2.6.0.3: copying precompiled package
semigroups-0.16.2.2: copying precompiled package
json-builder-0.3: copying precompiled package
attoparsec-0.12.1.6: copying precompiled package
HTTP-4000.2.20: copying precompiled package
bifunctors-5: copying precompiled package
void-0.7: copying precompiled package
aeson-0.8.0.2: copying precompiled package
contravariant-1.3.2: copying precompiled package
comonad-4.2.7.2: copying precompiled package
profunctors-5.1.1: copying precompiled package
semigroupoids-5.0.0.4: copying precompiled package
free-4.12.1: copying precompiled package
adjunctions-4.2.1: copying precompiled package
kan-extensions-4.2.2: copying precompiled package
lens-4.12.3: copying precompiled package
lens-aeson-1.0.0.4: copying precompiled package

Not a single of my dependencies was actually rebuilt! How awesome is that!

Thanks,
Micha?

On Fri, Sep 4, 2015 at 1:41 PM, Michal Antkiewicz <mantkiew at gsd.uwaterloo.ca
> wrote:

> what a great release! Esp. the reuse of binaries between snapshots!
>
>
>>    - Support added for compiling with GHCJS
>>
>> I presume that stack does not assist in installing GHCJS itself as it
> does for ghc. Are there any plans of improving the ghcjs situation? What
> are the current blockers?
>
> Thanks,
> Michal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/c2ad74cf/attachment.html>

From manny at fpcomplete.com  Fri Sep  4 18:34:25 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Fri, 4 Sep 2015 11:34:25 -0700
Subject: [Haskell-cafe] ANN: stack-0.1.4.0 (and 0.1.4.1)
In-Reply-To: <CAGW9QSxpWV0ymoMVy-SWLv=Ndp465zkkL0nsQ5Y8fUJH=D1mog@mail.gmail.com>
References: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
 <CAGW9QSxpWV0ymoMVy-SWLv=Ndp465zkkL0nsQ5Y8fUJH=D1mog@mail.gmail.com>
Message-ID: <CACGj5v+Q=nZjKxeUwOEi5Puzdf51SbjQ=oWFp299nJ0YCQUx4g@mail.gmail.com>

Yes, there are plans to have stack perform the GHCJS setup as well.  The
main blocker as I understand it is that GHCJS is not on Hackage yet (or
following any kind of "formal" release process), but Luite announced at HIW
that he intends to upload the first release soon.  Aside from that,
installing GHCJS is a very different process than installing GHC from a
bindist, so it's a matter of putting in the effort to develop and test it.

On Fri, Sep 4, 2015 at 10:41 AM, Michal Antkiewicz <
mantkiew at gsd.uwaterloo.ca> wrote:

> what a great release! Esp. the reuse of binaries between snapshots!
>
>
>>    - Support added for compiling with GHCJS
>>
>> I presume that stack does not assist in installing GHCJS itself as it
> does for ghc. Are there any plans of improving the ghcjs situation? What
> are the current blockers?
>
> Thanks,
> Michal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/f8c2b850/attachment.html>

From sven.bartscher at weltraumschlangen.de  Fri Sep  4 19:06:23 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Fri, 4 Sep 2015 21:06:23 +0200
Subject: [Haskell-cafe] GHC 7.8 undefined symbol
Message-ID: <20150904210623.050bf96d@sven.bartscher>

Greetings,

I recently installed a library (namely Hpysics, not on hackage) with
shared libraries (they were on by default).
When trying to do some stuff with the library (program attached), I get
a bunch of undefined symbol errors like this:

$ ghc --make Main.hs
Linking Main ...
/home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0x46e):
undefined reference to
`Hpysicszm0zi0_PhysicsziHpysicsziBoundingSphere_constructBoundingSpherezugo_info' /home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0x4f9):
undefined reference to
`Hpysicszm0zi0_PhysicsziHpysicsziBoundingSphere_zdwlgo_info' /home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0xaca6):
undefined reference to
`Hpysicszm0zi0_PhysicsziHpysicsziBoundingSphere_constructBoundingSpherezugo_info' /home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0xad31):
undefined reference to
`Hpysicszm0zi0_PhysicsziHpysicsziBoundingSphere_zdwlgo_info

Does anyone know, what this is about?

PS: Hpysics can be found at http://code.haskell.org/hpysics/

Regards
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.hs
Type: text/x-haskell
Size: 393 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/2a960370/attachment.hs>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/2a960370/attachment.sig>

From mgsloan at gmail.com  Fri Sep  4 19:07:14 2015
From: mgsloan at gmail.com (Michael Sloan)
Date: Fri, 04 Sep 2015 19:07:14 +0000
Subject: [Haskell-cafe] ANN: stack-0.1.4.0 (and 0.1.4.1)
In-Reply-To: <CACGj5v+Q=nZjKxeUwOEi5Puzdf51SbjQ=oWFp299nJ0YCQUx4g@mail.gmail.com>
References: <CACGj5v+4veO2mLpRiqDsP6oaQn=xp557Y9Xr6RUZSKP3MsWHRA@mail.gmail.com>
 <CAGW9QSxpWV0ymoMVy-SWLv=Ndp465zkkL0nsQ5Y8fUJH=D1mog@mail.gmail.com>
 <CACGj5v+Q=nZjKxeUwOEi5Puzdf51SbjQ=oWFp299nJ0YCQUx4g@mail.gmail.com>
Message-ID: <CAEDDsWfZYQJbeo7ueFSPZRgaUU4pA2gdtVs3Tt8HCX6ouOR4uw@mail.gmail.com>

Yup, a release of GHCJS is the main blocker.  Here's the issue tracking
this: https://github.com/commercialhaskell/stack/issues/749

-Michael

On Fri, Sep 4, 2015 at 11:34 AM Emanuel Borsboom <manny at fpcomplete.com>
wrote:

> Yes, there are plans to have stack perform the GHCJS setup as well.  The
> main blocker as I understand it is that GHCJS is not on Hackage yet (or
> following any kind of "formal" release process), but Luite announced at HIW
> that he intends to upload the first release soon.  Aside from that,
> installing GHCJS is a very different process than installing GHC from a
> bindist, so it's a matter of putting in the effort to develop and test it.
>
>
> On Fri, Sep 4, 2015 at 10:41 AM, Michal Antkiewicz <
> mantkiew at gsd.uwaterloo.ca> wrote:
>
>> what a great release! Esp. the reuse of binaries between snapshots!
>>
>>
>>>    - Support added for compiling with GHCJS
>>>
>>> I presume that stack does not assist in installing GHCJS itself as it
>> does for ghc. Are there any plans of improving the ghcjs situation? What
>> are the current blockers?
>>
>> Thanks,
>> Michal
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/cd4af304/attachment.html>

From allbery.b at gmail.com  Fri Sep  4 19:12:20 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 4 Sep 2015 15:12:20 -0400
Subject: [Haskell-cafe] GHC 7.8 undefined symbol
In-Reply-To: <20150904210623.050bf96d@sven.bartscher>
References: <20150904210623.050bf96d@sven.bartscher>
Message-ID: <CAKFCL4WNsX9wsqPAt5EtP=Y4fVjJekqJcZDpYiaY7JshfF7XoA@mail.gmail.com>

On Fri, Sep 4, 2015 at 3:06 PM, Sven Bartscher <
sven.bartscher at weltraumschlangen.de> wrote:

> I recently installed a library (namely Hpysics, not on hackage) with
> shared libraries (they were on by default).
> When trying to do some stuff with the library (program attached), I get
> a bunch of undefined symbol errors like this:
>
> $ ghc --make Main.hs
> Linking Main ...
>
> /home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0x46e):
> undefined reference to
> `Hpysicszm0zi0_PhysicsziHpysicsziBoundingSphere_constructBoundingSpherezugo_info'
> /home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0x4f9):
>

Physics.Hpysics.BoundingSphere is missing from extra-modules in Hpysics'
cabal file.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/024b2e54/attachment.html>

From allbery.b at gmail.com  Fri Sep  4 19:16:24 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 4 Sep 2015 15:16:24 -0400
Subject: [Haskell-cafe] GHC 7.8 undefined symbol
In-Reply-To: <CAKFCL4WNsX9wsqPAt5EtP=Y4fVjJekqJcZDpYiaY7JshfF7XoA@mail.gmail.com>
References: <20150904210623.050bf96d@sven.bartscher>
 <CAKFCL4WNsX9wsqPAt5EtP=Y4fVjJekqJcZDpYiaY7JshfF7XoA@mail.gmail.com>
Message-ID: <CAKFCL4U3D1bYVtMjPdoMxfmSxtsfLkmAmi5c14O0y3gWPVjaUg@mail.gmail.com>

On Fri, Sep 4, 2015 at 3:12 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> Physics.Hpysics.BoundingSphere is missing from extra-modules in Hpysics'
> cabal file.


Sorry, it's other-modules:, not extra-modules:.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/743d267f/attachment.html>

From sven.bartscher at weltraumschlangen.de  Fri Sep  4 19:33:14 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Fri, 4 Sep 2015 21:33:14 +0200
Subject: [Haskell-cafe] GHC 7.8 undefined symbol
In-Reply-To: <CAKFCL4WNsX9wsqPAt5EtP=Y4fVjJekqJcZDpYiaY7JshfF7XoA@mail.gmail.com>
References: <20150904210623.050bf96d@sven.bartscher>
 <CAKFCL4WNsX9wsqPAt5EtP=Y4fVjJekqJcZDpYiaY7JshfF7XoA@mail.gmail.com>
Message-ID: <20150904213314.5f939392@sven.bartscher>

On Fri, 4 Sep 2015 15:12:20 -0400
Brandon Allbery <allbery.b at gmail.com> wrote:

> On Fri, Sep 4, 2015 at 3:06 PM, Sven Bartscher <
> sven.bartscher at weltraumschlangen.de> wrote:
> 
> > I recently installed a library (namely Hpysics, not on hackage) with
> > shared libraries (they were on by default).
> > When trying to do some stuff with the library (program attached), I get
> > a bunch of undefined symbol errors like this:
> >
> > $ ghc --make Main.hs
> > Linking Main ...
> >
> > /home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0x46e):
> > undefined reference to
> > `Hpysicszm0zi0_PhysicsziHpysicsziBoundingSphere_constructBoundingSpherezugo_info'
> > /home/sven/.cabal/lib/i386-linux-ghc-7.8.4/Hpysics-0.0/libHSHpysics-0.0.a(Body.o):(.text+0x4f9):
> >
> 
> Physics.Hpysics.BoundingSphere is missing from extra-modules in Hpysics'
> cabal file.

Thanks! Correcting that did indeed work.
I think you actually meant other-modules, but I was able to at least
figure that out, by myself.

Regards and thanks
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150904/f2e8d924/attachment.sig>

From sven.bartscher at weltraumschlangen.de  Sat Sep  5 08:29:06 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Sat, 5 Sep 2015 10:29:06 +0200
Subject: [Haskell-cafe] Physics engine for Haskell
In-Reply-To: <op.x4f8sbktpz0j5l@alquantor>
References: <20150904151344.38f12fa7@sven.bartscher>
 <op.x4f8sbktpz0j5l@alquantor>
Message-ID: <20150905102906.0af89482@sven.bartscher>

On Fri, 04 Sep 2015 19:42:01 +0200
"Henk-Jan van Tuyl" <hjgtuyl at chello.nl> wrote:

> On Fri, 04 Sep 2015 15:13:44 +0200, Sven Bartscher  
> <sven.bartscher at weltraumschlangen.de> wrote:
> 
> > Greetings,
> >
> > I'm looking for a game physics engine for Haskell. As Bullet is widely
> > used in this field, I went to use the Haskell Bullet binding, but had
> > to find, that it is very inconvenient to use, because of things like
> > making optional parameters necessary in the binding.
> >
> > Is there any higher level binding to Bullet or some other Physics
> > library that is more convenient to use on Haskell?
> >
> > Regards
> > Sven
> 
> See:
>    https://wiki.haskell.org/Applications_and_libraries/Games#Game_Engines_and_Libraries
> I don't have experience with these packages, so I don't know how  
> convenient they are.

Thanks for the pointer. Hpysics looks nice, just a bit bitrotted. So,
after polishing it up, it might work just fine.

Regards
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/d8ebe2b7/attachment.sig>

From sven.bartscher at weltraumschlangen.de  Sat Sep  5 08:43:43 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Sat, 5 Sep 2015 10:43:43 +0200
Subject: [Haskell-cafe] Anyone familiar with Hpysics?
Message-ID: <20150905104343.14da7197@sven.bartscher>

Greetings,

I recently found the physic library/engine Hpysics. It looks really
nice and would like to use it for a project, because it's more natural
to use in Haskell, than Bullet is.

The problem with the library, seems to be, that it doesn't seem, like
it retrieved a lot of maintainer attention lately, e.g. after
downloading it, I had to fix some type errors in the library (some
incompatibility to GL floats), to get it working.

The author field in the .cabal file lacks an email, so I can't contact
him and ask if he still cares about the package.

Given that there doesn't seem to be an active maintainer and I need the
package, I would be willing to take over its maintenance.

The documentation is not really verbose about most stuff, so there are
some things, where I don't know how they are supposed to work.

Is there maybe someone, who was involved in writing the library or
maintaining it, or someone, who just used it and can help me, with
getting it in shape again, or maybe someone, who still feels
responsible for it and just didn't update it, because there was no
interest?

PS: The package can be found on http://code.haskell.org/hpysics/, but
not on hackage (another reason, why I believe it's not actively
mantained anymore).

Regards
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/24e5b8db/attachment.sig>

From roma at ro-che.info  Sat Sep  5 11:38:31 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 5 Sep 2015 14:38:31 +0300
Subject: [Haskell-cafe] Anyone familiar with Hpysics?
In-Reply-To: <20150905104343.14da7197@sven.bartscher>
References: <20150905104343.14da7197@sven.bartscher>
Message-ID: <55EAD437.9030006@ro-che.info>

Hi Sven,

I'm the author; Hpysics was my Google Summer of Code project back in 2008.

I've lost interest in this area since then. I might be able to answer
some basic questions; but mostly, you're on your own. I also wrote an
article for The Monad Reader about hpysics, it might be helpful:
https://wiki.haskell.org/wikiupload/f/f0/TMR-Issue12.pdf

From what I remember, hpysics had fairly basic functionality (collision
detection and response), so be prepared to do a lot of stuff yourself.
If you want to *use* a physics engine rather than *develop* one, you
should probably look into other projects.


On 05/09/15 11:43, Sven Bartscher wrote:
> Greetings,
> 
> I recently found the physic library/engine Hpysics. It looks really
> nice and would like to use it for a project, because it's more natural
> to use in Haskell, than Bullet is.
> 
> The problem with the library, seems to be, that it doesn't seem, like
> it retrieved a lot of maintainer attention lately, e.g. after
> downloading it, I had to fix some type errors in the library (some
> incompatibility to GL floats), to get it working.
> 
> The author field in the .cabal file lacks an email, so I can't contact
> him and ask if he still cares about the package.
> 
> Given that there doesn't seem to be an active maintainer and I need the
> package, I would be willing to take over its maintenance.
> 
> The documentation is not really verbose about most stuff, so there are
> some things, where I don't know how they are supposed to work.
> 
> Is there maybe someone, who was involved in writing the library or
> maintaining it, or someone, who just used it and can help me, with
> getting it in shape again, or maybe someone, who still feels
> responsible for it and just didn't update it, because there was no
> interest?
> 
> PS: The package can be found on http://code.haskell.org/hpysics/, but
> not on hackage (another reason, why I believe it's not actively
> mantained anymore).
> 
> Regards
> Sven
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/31bdfd5e/attachment-0001.sig>

From sven.bartscher at weltraumschlangen.de  Sat Sep  5 11:53:24 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Sat, 5 Sep 2015 13:53:24 +0200
Subject: [Haskell-cafe] Anyone familiar with Hpysics?
In-Reply-To: <55EAD437.9030006@ro-che.info>
References: <20150905104343.14da7197@sven.bartscher>
 <55EAD437.9030006@ro-che.info>
Message-ID: <20150905135324.2f8752bc@sven.bartscher>

On Sat, 5 Sep 2015 14:38:31 +0300
Roman Cheplyaka <roma at ro-che.info> wrote:

> Hi Sven,
> 
> I'm the author; Hpysics was my Google Summer of Code project back in 2008.
> 
> I've lost interest in this area since then. I might be able to answer
> some basic questions; but mostly, you're on your own. I also wrote an
> article for The Monad Reader about hpysics, it might be helpful:
> https://wiki.haskell.org/wikiupload/f/f0/TMR-Issue12.pdf

Thanks for your answer and offer!

> From what I remember, hpysics had fairly basic functionality (collision
> detection and response), so be prepared to do a lot of stuff yourself.
> If you want to *use* a physics engine rather than *develop* one, you
> should probably look into other projects.

That mirrors my observations (after the first mail). Friction seems to
be missing and some utilities known from bullet, like actors and
vehicles, seem to be missing. So I guess I will have to use something
else instead.

Regards
Sven

> On 05/09/15 11:43, Sven Bartscher wrote:
> > Greetings,
> > 
> > I recently found the physic library/engine Hpysics. It looks really
> > nice and would like to use it for a project, because it's more natural
> > to use in Haskell, than Bullet is.
> > 
> > The problem with the library, seems to be, that it doesn't seem, like
> > it retrieved a lot of maintainer attention lately, e.g. after
> > downloading it, I had to fix some type errors in the library (some
> > incompatibility to GL floats), to get it working.
> > 
> > The author field in the .cabal file lacks an email, so I can't contact
> > him and ask if he still cares about the package.
> > 
> > Given that there doesn't seem to be an active maintainer and I need the
> > package, I would be willing to take over its maintenance.
> > 
> > The documentation is not really verbose about most stuff, so there are
> > some things, where I don't know how they are supposed to work.
> > 
> > Is there maybe someone, who was involved in writing the library or
> > maintaining it, or someone, who just used it and can help me, with
> > getting it in shape again, or maybe someone, who still feels
> > responsible for it and just didn't update it, because there was no
> > interest?
> > 
> > PS: The package can be found on http://code.haskell.org/hpysics/, but
> > not on hackage (another reason, why I believe it's not actively
> > mantained anymore).
> > 
> > Regards
> > Sven
> > 
> > 
> > 
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/093ecb85/attachment.sig>

From ariep at xs4all.nl  Sat Sep  5 14:38:56 2015
From: ariep at xs4all.nl (Arie Peterson)
Date: Sat, 05 Sep 2015 16:38:56 +0200
Subject: [Haskell-cafe] Problem with lifted-async
In-Reply-To: <20150904122620.GA2088@rhea>
References: <20150904122620.GA2088@rhea>
Message-ID: <5815679.CObdo4Ese7@a4>

> ex.hs:20:20:
>     Couldn't match type ?StM t a0? with ?StM t a?
>     NB: ?StM? is a type function, and may not be injective
>     The type variable ?a0? is ambiguous
>     Expected type: Async (StM t a0)
>       Actual type: Async (StM t a)
>     Relevant bindings include
>       as :: Async (StM t a) (bound at ex.hs:19:30)
>       t :: Task t a (bound at ex.hs:19:28)
>       td :: TaskDescriptor t (bound at ex.hs:19:10)
>       pollTask :: TaskDescriptor t
>                   -> TaskDescriptor t -> t (TaskDescriptor t)
>         (bound at ex.hs:19:1)
>     In the first argument of ?poll?, namely ?as?
>     In a stmt of a 'do' block: st <- poll as
> Failed, modules loaded: none.

A working version can be found at the bottom of this message: essentially you 
need to explain to GHC that the 'a' and 'a0' from the above error message are 
in fact the same.

The problem is indeed, as GHC suggests, that the StM type family might not be 
injective. The signature of 'poll' is

  poll :: forall m a0. MonadBaseControl IO m => Async (StM m a0) -> m (Maybe 
(Either SomeException a0))

Now, 'poll' is fed the argument 'as', which has type Async (StM m a), where 
'a' is from opening the existential TaskDescriptor type. GHC combines this 
with the type of 'poll', and concludes that Async (StM m a) ~ Async (StM m 
a0). Now, we would like to conclude from this that a ~ a0, but this is not a 
valid conclusion, exactly because of this possible non-injectivity of StM. 
Because the return value of 'poll' is not used quite that fully, there is no 
way for the compiler to infer what the type variable 'a0' should be 
instantiated with.

Another way to fix this is to use the return value of 'poll' in such a way that 
'a0' must equal 'a', for example by replacing the line

  Just r -> runTask t

by

  Just r -> runTask (case r of Left _ -> t; Right a -> Task (return a))

That way, you don't need the below scoped type variables workaround.

(BTW: perhaps the LHS of 'pollTask' should be

  pollTask td@(TaskDescriptor t as)

, with the @ ? Doesn't really matter for the problem at hand, though.)

Regards,

Arie


==== ? ====
{-# LANGUAGE ExistentialQuantification  #-}
{-# LANGUAGE FlexibleContexts           #-}
{-# LANGUAGE ScopedTypeVariables        #-}

import Control.Concurrent.Async.Lifted (Async,async,asyncBound,poll,cancel)
import Control.Monad.Trans.Control (MonadBaseControl,StM)
import Control.Exception.Base (SomeException)

data Task m a = Task {
    taskVal   :: m a
}

data TaskDescriptor m = forall a. TaskDescriptor {
    task        :: Task m a,
    asyncThread :: Async (StM m a)
}

runTask :: forall a m. (MonadBaseControl IO m) => Task m a -> m 
(TaskDescriptor m)
runTask = undefined

pollTask td(TaskDescriptor (t :: Task m a) as) = do
        st :: Maybe (Either SomeException a) <- poll as
        case st of
            Nothing -> return td
            Just r -> runTask t

main = undefined
==== ? ====

From sven.bartscher at weltraumschlangen.de  Sat Sep  5 15:27:11 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Sat, 5 Sep 2015 17:27:11 +0200
Subject: [Haskell-cafe] Bullet bindings with Bullet 2.83
Message-ID: <20150905172711.332d99cc@sven.bartscher>

Greetings,

I'm trying to get the bullet binding working with Bullet 2.83.5.
I installed libbullet-dev 2.83.5 from the Debian testing archive (I'm
running Debian Stretch) and installed the Haskell binding
(with cabal install --enable-documentation).

Compiling the example results in a bunch of undefined reference errors
like this:

/home/sven/.cabal/lib/i386-linux-ghc-7.8.4/bullet-0.2.4/libHSbullet-0.2.4.a(Bullet.o):(.data.rel.ro._ZTV20btTetrahedronShapeEx[_ZTV20btTetrahedronShapeEx]+0x60):
undefined reference to
`btPolyhedralConvexShape::initializePolyhedralFeatures()'

I guess this is because, the Debian package doesn't come with a static
bullet libary, so I tried to compile it with dynamic libraries (with
the -dynamic flag), but it just fails with other undefined references.

The installation instructions for the Bullet binding say, it works with
Bullet 2.73, so I'm afraid this is some version incompatibility.

Does anyone know, how to get the binding working with Bullet 2.83 or
what other causes the missing symbols can have?

Regards
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/65b7e6b9/attachment.sig>

From lanablack at amok.cc  Sat Sep  5 18:51:48 2015
From: lanablack at amok.cc (Lana Black)
Date: Sat, 5 Sep 2015 18:51:48 +0000
Subject: [Haskell-cafe] Problem with lifted-async
In-Reply-To: <5815679.CObdo4Ese7@a4>
References: <20150904122620.GA2088@rhea>
 <5815679.CObdo4Ese7@a4>
Message-ID: <20150905185127.GA28954@glow>

On 16:38 Sat 05 Sep     , Arie Peterson wrote:
> A working version can be found at the bottom of this message: essentially you 
> need to explain to GHC that the 'a' and 'a0' from the above error message are 
> in fact the same.
> 
> The problem is indeed, as GHC suggests, that the StM type family might not be 
> injective. The signature of 'poll' is
> 
>   poll :: forall m a0. MonadBaseControl IO m => Async (StM m a0) -> m (Maybe 
> (Either SomeException a0))
> 
> Now, 'poll' is fed the argument 'as', which has type Async (StM m a), where 
> 'a' is from opening the existential TaskDescriptor type. GHC combines this 
> with the type of 'poll', and concludes that Async (StM m a) ~ Async (StM m 
> a0). Now, we would like to conclude from this that a ~ a0, but this is not a 
> valid conclusion, exactly because of this possible non-injectivity of StM. 
> Because the return value of 'poll' is not used quite that fully, there is no 
> way for the compiler to infer what the type variable 'a0' should be 
> instantiated with.
> 
> Another way to fix this is to use the return value of 'poll' in such a way that 
> 'a0' must equal 'a', for example by replacing the line
> 
>   Just r -> runTask t
> 
> by
> 
>   Just r -> runTask (case r of Left _ -> t; Right a -> Task (return a))
> 
> That way, you don't need the below scoped type variables workaround.

Great! That solved it. Thank you.

> (BTW: perhaps the LHS of 'pollTask' should be
> 
>   pollTask td@(TaskDescriptor t as)
> 
> , with the @ ? Doesn't really matter for the problem at hand, though.)

That was just a minimal example showing the problem. The actual code is
a bit longer.

From andrew.gibiansky at gmail.com  Sat Sep  5 22:55:37 2015
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Sat, 5 Sep 2015 15:55:37 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
Message-ID: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>

I'd like to propose a GHC extension called (for now) `ArgumentBody`.
`ArgumentBody` is a simple syntax extension, than, when enabled, permits
the following code:

main = when True do
  putStrLn "Hello!"


main = forM values \value ->
  print value


main = forM values \case
    Just x -> print x
    Nothing -> print y


In this code we do not need `$` before `do`, lambda, or lambda-case (if
-XLambdaCase is enabled). This change would *not* extend to `let`, `if`,
`case`, or any other constructs.

Pros:

1. Code is simpler and it greatly reduces the need for "operator line
noise" of $ everywhere.
2. We can avoid using the type-checker hack for $
<http://stackoverflow.com/questions/9468963/runst-and-function-composition>
for things such as runSt.

Cons:

1. Adds complexity to the compiler. (NB: The change is minimal and not
invasive at all.)
2. Contributes to a proliferation of extensions that other tools must
support.  (NB: This is just a parser change so should be easy for all tools
to support.)

I'm very interested in hearing both favoring and dissenting opinions on
this proposed change. If this change is approved of, names besides
-XArgumentBody can be considered.

See more info on Trac <https://ghc.haskell.org/trac/ghc/ticket/10843#ticket>
.

-- Andrew Gibiansky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/225f0760/attachment.html>

From will.yager at gmail.com  Sun Sep  6 00:12:47 2015
From: will.yager at gmail.com (William Yager)
Date: Sat, 5 Sep 2015 19:12:47 -0500
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <CAG8oi1Ms+OiXa7G7V+hDuEYqwVLNA7sUaztOT3PRGrM9Qu-FAQ@mail.gmail.com>

+1. I have often wanted this feature. Not only does it remove syntactic
noise, but it makes basic do-syntax much more approachable for newbies.

--Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/0b82f1be/attachment.html>

From vagarenko at gmail.com  Sun Sep  6 06:17:27 2015
From: vagarenko at gmail.com (Alexey Vagarenko)
Date: Sat, 5 Sep 2015 23:17:27 -0700 (PDT)
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>

-1.
Creating a language extension just to get rid of a single character is 
overkill.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150905/dc5bdcb2/attachment.html>

From ollie at ocharles.org.uk  Sun Sep  6 06:22:43 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Sun, 06 Sep 2015 06:22:43 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
Message-ID: <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>

I'm loosely in favour of this for 'do', not quite so keen for lambda
expressions - but I have no justifiable reason why, other than "it looks a
bit weird".

I don't really like $ from an editor perspective though (tooling has to
become aware of a single function when performing refactorings), so
anything that helps reduce how prolific that operator is is a win in my
book!

Is the following going to be valid code under your extension?

   runReaderT
     do foo
        bar
     env

Likewise, I expect the following also parses:

import Control.Monad

main :: IO ()
main = when True
         do print "Hello"

- Ollie

On Sun, Sep 6, 2015 at 7:17 AM Alexey Vagarenko <vagarenko at gmail.com> wrote:

> -1.
> Creating a language extension just to get rid of a single character is
> overkill.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/83473152/attachment.html>

From spam at scientician.net  Sun Sep  6 06:57:52 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sun, 6 Sep 2015 08:57:52 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <msgo5g$dub$1@ger.gmane.org>

On 09/06/2015 12:55 AM, Andrew Gibiansky wrote:
> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> the following code:
> 

-1, too little gain for Yet Another Extension.

It also reduces "regularity".


From ivan.miljenovic at gmail.com  Sun Sep  6 11:42:14 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 6 Sep 2015 21:42:14 +1000
Subject: [Haskell-cafe] ANNOUNCE: graphviz-2999.18.0.0
Message-ID: <CA+u6gbxDU_2h54wWSyZQBWyrMy4GPH8F=Ebz4MLGnKKshb_6yQ@mail.gmail.com>

This is my "sorry it took so long" release: I'd like to apologise to
all the people that have been nagging^W gently asking me when a GHC
7.10.*-compatible release would be available that it's taken me until
now to do this, but I'm finally pleased to be able to say that you can
now use my graphviz library to generate/parse Dot code and visualise
graphs using the Graphviz suite of tools.

As part of this version release, graphviz is now developed using git
and can be found on GitHub: https://github.com/ivan-m/graphviz

The major version bump is due to an extra attribute being made
available, so in most (all?) cases you can safely version bump your
existing dependencies.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From kane at kane.cx  Sun Sep  6 12:32:02 2015
From: kane at kane.cx (David Kraeutmann)
Date: Sun, 6 Sep 2015 14:32:02 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <msgo5g$dub$1@ger.gmane.org>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
Message-ID: <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>

-1, doesn't add anything useful other than saving a character.
Besides, I don't like how those snippets look without $. Seems off to
me.

On Sun, Sep 6, 2015 at 8:57 AM, Bardur Arantsson <spam at scientician.net> wrote:
> On 09/06/2015 12:55 AM, Andrew Gibiansky wrote:
>> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
>> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
>> the following code:
>>
>
> -1, too little gain for Yet Another Extension.
>
> It also reduces "regularity".
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From ollie at ocharles.org.uk  Sun Sep  6 12:34:55 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Sun, 06 Sep 2015 12:34:55 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
Message-ID: <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>

People saying "it just saves a character" seems to have completely missed
my point and source code readability/refactoring options from a tool's
perspective. It does more than save a character.

On Sun, Sep 6, 2015 at 1:32 PM David Kraeutmann <kane at kane.cx> wrote:

> -1, doesn't add anything useful other than saving a character.
> Besides, I don't like how those snippets look without $. Seems off to
> me.
>
> On Sun, Sep 6, 2015 at 8:57 AM, Bardur Arantsson <spam at scientician.net>
> wrote:
> > On 09/06/2015 12:55 AM, Andrew Gibiansky wrote:
> >> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> >> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> >> the following code:
> >>
> >
> > -1, too little gain for Yet Another Extension.
> >
> > It also reduces "regularity".
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/7ae76429/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Sep  6 12:45:47 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 6 Sep 2015 13:45:47 +0100
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
Message-ID: <20150906124547.GF14413@weber>

On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> People saying "it just saves a character" seems to have completely missed
> my point and source code readability/refactoring options from a tool's
> perspective. It does more than save a character.

Let's look at it from the opposite direction.  If "ArgumentBlock" were
already the default then we could remove complexity from the grammar for the
cost of a single character.  That sounds like a great tradeoff to me, and is
the reason I can't support ArgumentBlock.

Tom

From ivan.miljenovic at gmail.com  Sun Sep  6 12:48:52 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 6 Sep 2015 22:48:52 +1000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <20150906124547.GF14413@weber>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
 <20150906124547.GF14413@weber>
Message-ID: <CA+u6gbzh=yLvori7s1gXJBGWPOuABBuV8aw=1BcGe_nJovEghw@mail.gmail.com>

-1 for me, as I think the examples make it look *more* ambiguous.

Whilst it can be a pain to have to remember to add the $, there's less
immediate information that the `do`, lambdas, etc. form a new block
and are not just individual word arguments to the calling function.

On 6 September 2015 at 22:45, Tom Ellis
<tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
>> People saying "it just saves a character" seems to have completely missed
>> my point and source code readability/refactoring options from a tool's
>> perspective. It does more than save a character.
>
> Let's look at it from the opposite direction.  If "ArgumentBlock" were
> already the default then we could remove complexity from the grammar for the
> cost of a single character.  That sounds like a great tradeoff to me, and is
> the reason I can't support ArgumentBlock.
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From ollie at ocharles.org.uk  Sun Sep  6 12:52:04 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Sun, 06 Sep 2015 12:52:04 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <20150906124547.GF14413@weber>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
 <20150906124547.GF14413@weber>
Message-ID: <CAGRp5Rk_Myp0O3HtkB8SFB+UxJVc0LHY1OvUse2YJk-6JKTCkw@mail.gmail.com>

On Sun, Sep 6, 2015 at 1:46 PM Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> > People saying "it just saves a character" seems to have completely missed
> > my point and source code readability/refactoring options from a tool's
> > perspective. It does more than save a character.
>
> Let's look at it from the opposite direction.  If "ArgumentBlock" were
> already the default then we could remove complexity from the grammar for
> the
> cost of a single character.  That sounds like a great tradeoff to me, and
> is
> the reason I can't support ArgumentBlock.
>

Really? You would rather increase syntactic complexity just to make the
parser code simpler?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/b7947d0b/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Sep  6 12:53:04 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 6 Sep 2015 13:53:04 +0100
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <20150906125303.GG14413@weber>

On Sat, Sep 05, 2015 at 03:55:37PM -0700, Andrew Gibiansky wrote:
> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> the following code:
> 
> main = when True do
>   putStrLn "Hello!"
> 
> 
> main = forM values \value ->
>   print value
> 
> 
> main = forM values \case
>     Just x -> print x
>     Nothing -> print y

By the way, you can already do

main = when True (do
  putStrLn "Hello!")


main = forM values (\value ->
  print value)


main = forM values (\case
    Just x -> print x
    Nothing -> print y)

which gets you a lot of the way, and is arguably even clearer.  This is as
style that has been promoted by Chris Done.

Tom

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Sep  6 12:53:44 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 6 Sep 2015 13:53:44 +0100
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGRp5Rk_Myp0O3HtkB8SFB+UxJVc0LHY1OvUse2YJk-6JKTCkw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
 <20150906124547.GF14413@weber>
 <CAGRp5Rk_Myp0O3HtkB8SFB+UxJVc0LHY1OvUse2YJk-6JKTCkw@mail.gmail.com>
Message-ID: <20150906125344.GH14413@weber>

On Sun, Sep 06, 2015 at 12:52:04PM +0000, Oliver Charles wrote:
> On Sun, Sep 6, 2015 at 1:46 PM Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> 
> > On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> > > People saying "it just saves a character" seems to have completely missed
> > > my point and source code readability/refactoring options from a tool's
> > > perspective. It does more than save a character.
> >
> > Let's look at it from the opposite direction.  If "ArgumentBlock" were
> > already the default then we could remove complexity from the grammar for
> > the
> > cost of a single character.  That sounds like a great tradeoff to me, and
> > is
> > the reason I can't support ArgumentBlock.
> 
> Really? You would rather increase syntactic complexity just to make the
> parser code simpler?

On the contrary, I consider it a *decrease* in syntactic complexity!

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Sep  6 12:55:58 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 6 Sep 2015 13:55:58 +0100
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <20150906125344.GH14413@weber>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
 <20150906124547.GF14413@weber>
 <CAGRp5Rk_Myp0O3HtkB8SFB+UxJVc0LHY1OvUse2YJk-6JKTCkw@mail.gmail.com>
 <20150906125344.GH14413@weber>
Message-ID: <20150906125558.GI14413@weber>

On Sun, Sep 06, 2015 at 01:53:44PM +0100, Tom Ellis wrote:
> On Sun, Sep 06, 2015 at 12:52:04PM +0000, Oliver Charles wrote:
> > On Sun, Sep 6, 2015 at 1:46 PM Tom Ellis <
> > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> > 
> > > On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
> > > > People saying "it just saves a character" seems to have completely missed
> > > > my point and source code readability/refactoring options from a tool's
> > > > perspective. It does more than save a character.
> > >
> > > Let's look at it from the opposite direction.  If "ArgumentBlock" were
> > > already the default then we could remove complexity from the grammar for
> > > the
> > > cost of a single character.  That sounds like a great tradeoff to me, and
> > > is
> > > the reason I can't support ArgumentBlock.
> > 
> > Really? You would rather increase syntactic complexity just to make the
> > parser code simpler?
> 
> On the contrary, I consider it a *decrease* in syntactic complexity!

It's nothing to do with the "parser code", by the way.  It's to minimize
what I have to keep in my own head when writing code.

From kane at kane.cx  Sun Sep  6 13:03:20 2015
From: kane at kane.cx (David Kraeutmann)
Date: Sun, 6 Sep 2015 15:03:20 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <20150906124547.GF14413@weber>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
 <20150906124547.GF14413@weber>
Message-ID: <CAJ8B99zoNT_r2RcdfaFGzK1ezjkfwd0yRmwC7B6PkfEFqySY+A@mail.gmail.com>

It's not something that belongs in an extension. Rather, it should be
in the main language.

Let's say you want to write f (\x -> x) (\y -> y) and forget the parentheses.

How would you parse the following under ArgumentBlock:
f \x -> x \y -> y?


On Sun, Sep 6, 2015 at 2:45 PM, Tom Ellis
<tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
>> People saying "it just saves a character" seems to have completely missed
>> my point and source code readability/refactoring options from a tool's
>> perspective. It does more than save a character.
>
> Let's look at it from the opposite direction.  If "ArgumentBlock" were
> already the default then we could remove complexity from the grammar for the
> cost of a single character.  That sounds like a great tradeoff to me, and is
> the reason I can't support ArgumentBlock.
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From lists at andy-morris.xyz  Sun Sep  6 14:38:15 2015
From: lists at andy-morris.xyz (Andrew Morris)
Date: Sun, 6 Sep 2015 15:38:15 +0100
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJ8B99zoNT_r2RcdfaFGzK1ezjkfwd0yRmwC7B6PkfEFqySY+A@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
 <20150906124547.GF14413@weber>
 <CAJ8B99zoNT_r2RcdfaFGzK1ezjkfwd0yRmwC7B6PkfEFqySY+A@mail.gmail.com>
Message-ID: <5C8BBB85-48A6-4451-A111-2C948004F60A@andy-morris.xyz>

As `f (\x -> x (\y -> y))`.

FWIW, I actually think it strange that these constructs are allowed as an argument to an infix function but not a nonfix one. So it seems to me that it would be _removing_ a weird exception rather than adding one. Assuming we add `let`, `case`, and the other things that can also be an argument to an infix op, that is. (Why are they being excluded, by the way?)

> On 6 Sep 2015, at 14:03, David Kraeutmann <kane at kane.cx> wrote:
> 
> It's not something that belongs in an extension. Rather, it should be
> in the main language.
> 
> Let's say you want to write f (\x -> x) (\y -> y) and forget the parentheses.
> 
> How would you parse the following under ArgumentBlock:
> f \x -> x \y -> y?
> 
> 
> On Sun, Sep 6, 2015 at 2:45 PM, Tom Ellis
> <tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>> On Sun, Sep 06, 2015 at 12:34:55PM +0000, Oliver Charles wrote:
>>> People saying "it just saves a character" seems to have completely missed
>>> my point and source code readability/refactoring options from a tool's
>>> perspective. It does more than save a character.
>> 
>> Let's look at it from the opposite direction.  If "ArgumentBlock" were
>> already the default then we could remove complexity from the grammar for the
>> cost of a single character.  That sounds like a great tradeoff to me, and is
>> the reason I can't support ArgumentBlock.
>> 
>> Tom
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From svenpanne at gmail.com  Sun Sep  6 15:24:52 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 6 Sep 2015 17:24:52 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
 <CAJ8B99xqgDM0vdsw4KCD3WN+TjR-nKzZuqALAM7032L3BLDU+w@mail.gmail.com>
 <CAGRp5R=SVG6ny59E8N+DOO6L0ssSJRNubXgyp+V8GQVaK_upQQ@mail.gmail.com>
Message-ID: <CANBN=mtzjHivU95vfM=QEDy0taHJf0p+Ct2rQfFVE+QSDObhqQ@mail.gmail.com>

2015-09-06 14:34 GMT+02:00 Oliver Charles <ollie at ocharles.org.uk>:

> People saying "it just saves a character" seems to have completely missed
> my point and source code readability/refactoring options from a tool's
> perspective. It does more than save a character.
>

Could you elaborate on the "refactoring options"? I don't fully understand
why requiring $ makes things *more* complicated for a tool. It seems to me
that introducing another irregularity (leaving out $) makes a tool's life
harder, not easier.

Regarding readability: This is a totally subjective thing, e.g. for me all
the examples without the $ look really, really horrible and confusing. To
me, the $ is a strong visual clue for "here comes an argument" which is
lost under the proposal. The point that there is no possible valid parse
without it is irrelevant IMHO: Programs are mainly meant to be read by
humans, not computers. Try parsing

  foo bar do baz boo do skooby doo

visually and compare that to the version with $.


Furthermore, I fully agree with others that introducing another syntactic
irregularity is bad from an aesthetic point of view. To make things worse,
the irregularity itself is itself, well, irregular by leaving out
let/if/case/...

And finally: There seems to be a trend recently to propose minor syntactic
"improvements". If they would be implemented, different people would pick
different subsets of these, effectively creating tons of dialects and
fragmenting the language.

In a nutshell: -1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/04cd320d/attachment.html>

From nicola.gigante at gmail.com  Sun Sep  6 17:29:23 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sun, 6 Sep 2015 19:29:23 +0200
Subject: [Haskell-cafe] Functional counterpart of counting-sort?
Message-ID: <853881CA-AAAA-414F-A34D-4C6B8CB55E24@gmail.com>

Hi all,

I?m sorry if this is a trivial question.

Everybody knows the counting sort algorithm to sort an array
of integer values, which runs in O(n) time, circumventing the O(n log n)
lower bound by avoiding comparison operations.

Of course, that only works for integers. However, it seems to
me that it essentially relies on the availability of a O(1) indexing
operation on the array, not on algebraic or logical properties of
the set of the integers.

Do any of you know if it is possible to sort a _list_ of integers in
O(n) time in a (lazy) purely functional language?

I?d say no, but given all the crazy laziness tricks out there,
I can?t say for sure ;)
Even if no: any theoretical considerations on why not?


Greetings,
Nicola


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Sep  6 17:36:36 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 6 Sep 2015 18:36:36 +0100
Subject: [Haskell-cafe] Functional counterpart of counting-sort?
In-Reply-To: <853881CA-AAAA-414F-A34D-4C6B8CB55E24@gmail.com>
References: <853881CA-AAAA-414F-A34D-4C6B8CB55E24@gmail.com>
Message-ID: <20150906173636.GK14413@weber>

On Sun, Sep 06, 2015 at 07:29:23PM +0200, Nicola Gigante wrote:
> Do any of you know if it is possible to sort a _list_ of integers in
> O(n) time in a (lazy) purely functional language?

Are you familiar with discrimination?

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

From matthewtpickering at gmail.com  Sun Sep  6 17:53:20 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sun, 6 Sep 2015 20:53:20 +0300
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
Message-ID: <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>

>
> I don't really like $ from an editor perspective though (tooling has to
> become aware of a single function when performing refactorings), so anything
> that helps reduce how prolific that operator is is a win in my book!
>

Can you please explain what you mean by this? Is there something more
subtle that $ being a low fixity operator? Which specific problems
does it cause tooling? Are you referring to the fact that there are
problems because $ == id and makes tooling account for two cases when
looking for refactorings? (I'm thinking of hlint here).

(FWIW, haskell-src-exts tries to fiddle with the AST to account for
fixity after parsing but the GHC parser does not, it happens during
renaming. There is a pure version here[1] if anyone else is in need of
this feature).

Thanks, Matt

From ollie at ocharles.org.uk  Sun Sep  6 18:03:00 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Sun, 06 Sep 2015 18:03:00 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
Message-ID: <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>

I mean that people us $ for purely syntactical purposes. If an editor is
going to make refactorings and retain a certain sense of style, then the
tool needs to know that $ is sometimes to be used. The refactoring (or
otherwise) tool now has to be aware of the syntax of Haskell and special
symbols in the Prelude.

On Sun, Sep 6, 2015 at 6:53 PM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> >
> > I don't really like $ from an editor perspective though (tooling has to
> > become aware of a single function when performing refactorings), so
> anything
> > that helps reduce how prolific that operator is is a win in my book!
> >
>
> Can you please explain what you mean by this? Is there something more
> subtle that $ being a low fixity operator? Which specific problems
> does it cause tooling? Are you referring to the fact that there are
> problems because $ == id and makes tooling account for two cases when
> looking for refactorings? (I'm thinking of hlint here).
>
> (FWIW, haskell-src-exts tries to fiddle with the AST to account for
> fixity after parsing but the GHC parser does not, it happens during
> renaming. There is a pure version here[1] if anyone else is in need of
> this feature).
>
> Thanks, Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/65080f81/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Sep  6 18:11:40 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 6 Sep 2015 19:11:40 +0100
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
Message-ID: <20150906181139.GL14413@weber>

On Sun, Sep 06, 2015 at 06:03:00PM +0000, Oliver Charles wrote:
> I mean that people us $ for purely syntactical purposes. If an editor is
> going to make refactorings and retain a certain sense of style, then the
> tool needs to know that $ is sometimes to be used. The refactoring (or
> otherwise) tool now has to be aware of the syntax of Haskell and special
> symbols in the Prelude.

It seems unlikely that making the tool aware of ($) is much more (or less)
difficult than making it aware of when it can omit brackets from a multiline
do, lambda etc.

From amos.robinson at gmail.com  Sun Sep  6 18:17:12 2015
From: amos.robinson at gmail.com (Amos Robinson)
Date: Sun, 06 Sep 2015 18:17:12 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <20150906181139.GL14413@weber>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
Message-ID: <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>

If you made tooling aware of ($) would you need to check that it is
importing the Prelude version and not another one? Not that I'm suggesting
that having a different implementation would be sensible.

This seems rather good to me. It seems sensible and I don't really see the
ambiguity.
On Sun, 6 Sep 2015 at 11:11 Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> On Sun, Sep 06, 2015 at 06:03:00PM +0000, Oliver Charles wrote:
> > I mean that people us $ for purely syntactical purposes. If an editor is
> > going to make refactorings and retain a certain sense of style, then the
> > tool needs to know that $ is sometimes to be used. The refactoring (or
> > otherwise) tool now has to be aware of the syntax of Haskell and special
> > symbols in the Prelude.
>
> It seems unlikely that making the tool aware of ($) is much more (or less)
> difficult than making it aware of when it can omit brackets from a
> multiline
> do, lambda etc.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/b7f4a51b/attachment.html>

From andrew.gibiansky at gmail.com  Sun Sep  6 18:28:05 2015
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Sun, 6 Sep 2015 11:28:05 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
Message-ID: <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>

A few more things to add to this discussion:

1. In terms of impact, I think it makes sense to view this extension as
similar to -XDoAndIfThenElse and -XLambdaCase. Both are similar in their
levels of complexity and add a similar amount of syntax. Would GHC be
better off without them? Or do we expect that some future version of GHC
may have one or both of them on by default? I think that if we *ever* want
to change basic Haskell syntax (such as DoAndIfThenElse and ArgumentBlock),
we have to start it off with an extension.

2. Following up on that, perhaps another way to view this question is: Do
we ever want this functionality to be part of standard Haskell? If not,
then I would vote against this extension, because it just adds
fragmentation. If there's a possibility that we may want to permanently
change default syntax a la ArgumentBlock, then we have to start off with an
extension. (FYI I believe it is a valid possibility, in that the extension
is inherently backwards compatible -- it should not break any code if it is
enabled, as it allows strictly more parses.)

3. It does make some cases cleaner. Consider the following code: [1, 2, 3]
++ concat (do { .... }). This can be written with parentheses, bit it
cannot be written with $, because [1, 2, 3] ++ concat $ do { .... } would
parse as ([1, 2, 3] ++ concat) $ do { ... }. This is sometimes annoying
behaviour. (I used the list monad here just for demo purposes. I find it is
more common with applicative operators.)

4. We can easily generalize this to include case, let, and so on. It was
written without support for them to limit the scope of the change, rather
than because it is not possible.

As an aside, my favorite comment so far is "All this because Haskellers are
allergic to parentheses ~chrisdone".

-- Andrew Gibiansky

On Sun, Sep 6, 2015 at 11:17 AM, Amos Robinson <amos.robinson at gmail.com>
wrote:

> If you made tooling aware of ($) would you need to check that it is
> importing the Prelude version and not another one? Not that I'm suggesting
> that having a different implementation would be sensible.
>
> This seems rather good to me. It seems sensible and I don't really see the
> ambiguity.
>
> On Sun, 6 Sep 2015 at 11:11 Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>
>> On Sun, Sep 06, 2015 at 06:03:00PM +0000, Oliver Charles wrote:
>> > I mean that people us $ for purely syntactical purposes. If an editor is
>> > going to make refactorings and retain a certain sense of style, then the
>> > tool needs to know that $ is sometimes to be used. The refactoring (or
>> > otherwise) tool now has to be aware of the syntax of Haskell and special
>> > symbols in the Prelude.
>>
>> It seems unlikely that making the tool aware of ($) is much more (or less)
>> difficult than making it aware of when it can omit brackets from a
>> multiline
>> do, lambda etc.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/c48ad214/attachment.html>

From targen at gmail.com  Sun Sep  6 19:03:28 2015
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Sun, 6 Sep 2015 14:33:28 -0430
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
Message-ID: <CAJWnFaO59nqeNacmZTuMZO=K+oVf=nR8i=En4v65hDBk0f4U9A@mail.gmail.com>

On Sun, Sep 6, 2015 at 1:58 PM, Andrew Gibiansky
<andrew.gibiansky at gmail.com> wrote:
>
> A few more things to add to this discussion:
>
> 1. In terms of impact, I think it makes sense to view this extension as similar to -XDoAndIfThenElse and -XLambdaCase. Both are similar in their levels of complexity and add a similar amount of syntax. Would GHC be better off without them? Or do we expect that some future version of GHC may have one or both of them on by default? I think that if we ever want to change basic Haskell syntax (such as DoAndIfThenElse and ArgumentBlock), we have to start it off with an extension.
>
> 2. Following up on that, perhaps another way to view this question is: Do we ever want this functionality to be part of standard Haskell? If not, then I would vote against this extension, because it just adds fragmentation. If there's a possibility that we may want to permanently change default syntax a la ArgumentBlock, then we have to start off with an extension. (FYI I believe it is a valid possibility, in that the extension is inherently backwards compatible -- it should not break any code if it is enabled, as it allows strictly more parses.)

It seems to me that lately the community?s visible attitude has
shifted toward a heightened value of stability and uniformity for
Haskell and its software ecosystem, and experimentation, fragmentation
and diversity in styles and dialects are now viewed as threatening.
This drives us to reject the process of gradual improvement that has
made Haskell great over the years.  Other similarly purely syntactic
extensions seem to me to have been met with less resistance in the
past.  It appears we?re now far more concerned with the pursuit of
success.

+1

From svenpanne at gmail.com  Sun Sep  6 19:48:45 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 6 Sep 2015 21:48:45 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
Message-ID: <CANBN=mv9oRAqC+tf6-HZJTgQd6VY-aAm0RYbQTViE=OtXtLHmQ@mail.gmail.com>

2015-09-06 20:17 GMT+02:00 Amos Robinson <amos.robinson at gmail.com>:

> If you made tooling aware of ($) would you need to check that it is
> importing the Prelude version and not another one?


Every non-toy refactoring tool (and I guess a lot of other ones) needs to
understand fixity declarations, imports, scopes etc. anyway, otherwise it
would be next to useless.


> Not that I'm suggesting that having a different implementation would be
> sensible.
>

"Sensible" is always a subjective notion, and tools should not have
subjective behavior. :-) In other words: If it's legal, the tool must
handle it. A lot of things which were initially considered
nonsense/impractical/confusing are mainstream nowadays. Furthermore, there
are a few experimental Prelude variants out there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/912ad319/attachment.html>

From kc1956 at gmail.com  Sun Sep  6 20:32:43 2015
From: kc1956 at gmail.com (KC)
Date: Sun, 6 Sep 2015 13:32:43 -0700
Subject: [Haskell-cafe] Can #Haskell be used to generate the #Java class
 libraries relatively error free? #Java8u60
Message-ID: <CAMLKXynUVei6vgwK3JjEYP_UmW9By3i6MKtZhyUr+ifooZmjrA@mail.gmail.com>

Can #Haskell be used to generate the #Java class libraries relatively error
free? #Java8u60

--
--

Sent from an expensive device which will be obsolete in a few months! :D

Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/9b9d6bd0/attachment.html>

From spopejoy at panix.com  Sun Sep  6 20:58:52 2015
From: spopejoy at panix.com (Stuart Popejoy)
Date: Sun, 06 Sep 2015 16:58:52 -0400
Subject: [Haskell-cafe] emacs haskell-mode with cabal exec,
	test suite sections
Message-ID: <55ECA90C.1040104@panix.com>

I'm having trouble coding test-suite and executable sections with
the emacs REPL and flycheck.

1. cabal-repl can compile against the library code, but fails to see any 
modules within the non-library section.

2. flycheck has the opposite problem: it fails on library module imports 
but recognizes imports local to the section.

Note I don't always have these issues, but they seem to crop up whenever 
I upgrade GHC, or emacs, or haskell-mode, flycheck-haskell etc.
I'm not sure #1 ever works, but #2 is happening to me on my mac, but not 
at work on Linux.

For #1, in the past I've tried a big .dir-locals.el to use `ghci` for 
the repl and just import everything -- of course losing the nice cabal 
integration, plus it being slow as molasses to load source files.

I also briefly investigated modifying haskell-mode to support separate 
sessions for a given section.

For #2, flycheck is just a pain to debug, my only recourse is to stick 
debug output into `flycheck-start-command-checker` to see what commands 
are going out, and try to troubleshoot.

Any thoughts or suggestions? Commiseration is OK too :)

Thanks,
Stuart

From ivan.miljenovic at gmail.com  Sun Sep  6 22:01:01 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Mon, 7 Sep 2015 08:01:01 +1000
Subject: [Haskell-cafe] emacs haskell-mode with cabal exec,
	test suite sections
In-Reply-To: <55ECA90C.1040104@panix.com>
References: <55ECA90C.1040104@panix.com>
Message-ID: <CA+u6gbzUDXeVv42K8NUD7kg=jWtdfme6-5zueWR3qXo23i_3hA@mail.gmail.com>

On 7 September 2015 at 06:58, Stuart Popejoy <spopejoy at panix.com> wrote:
> I'm having trouble coding test-suite and executable sections with
> the emacs REPL and flycheck.
>
> 1. cabal-repl can compile against the library code, but fails to see any
> modules within the non-library section.

haskell-session-change-target

>
> 2. flycheck has the opposite problem: it fails on library module imports but
> recognizes imports local to the section.

Yeah, it claims to have sandbox support but for some reason I've never
managed to get it to stop complaining about not being able to find
modules installed in the sandbox.

>
> Note I don't always have these issues, but they seem to crop up whenever I
> upgrade GHC, or emacs, or haskell-mode, flycheck-haskell etc.
> I'm not sure #1 ever works, but #2 is happening to me on my mac, but not at
> work on Linux.
>
> For #1, in the past I've tried a big .dir-locals.el to use `ghci` for the
> repl and just import everything -- of course losing the nice cabal
> integration, plus it being slow as molasses to load source files.
>
> I also briefly investigated modifying haskell-mode to support separate
> sessions for a given section.
>
> For #2, flycheck is just a pain to debug, my only recourse is to stick debug
> output into `flycheck-start-command-checker` to see what commands are going
> out, and try to troubleshoot.
>
> Any thoughts or suggestions? Commiseration is OK too :)
>
> Thanks,
> Stuart
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From fa-ml at ariis.it  Sun Sep  6 22:08:54 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Mon, 7 Sep 2015 00:08:54 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJWnFaO59nqeNacmZTuMZO=K+oVf=nR8i=En4v65hDBk0f4U9A@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <CAJWnFaO59nqeNacmZTuMZO=K+oVf=nR8i=En4v65hDBk0f4U9A@mail.gmail.com>
Message-ID: <20150906220854.GA16322@casa.casa>

On Sun, Sep 06, 2015 at 02:33:28PM -0430, Manuel G?mez wrote:
> It seems to me that lately the community?s visible attitude has
> shifted toward a heightened value of stability and uniformity for
> Haskell and its software ecosystem, and experimentation, fragmentation
> and diversity in styles and dialects are now viewed as threatening.
> This drives us to reject the process of gradual improvement that has
> made Haskell great over the years.  Other similarly purely syntactic
> extensions seem to me to have been met with less resistance in the
> past.  It appears we?re now far more concerned with the pursuit of
> success.
> 
> +1

Hello Manuel,
    your post made me clearly realise why I am sometimes unhappy about
syntactic extensions, so I'll take advantage of this discussion to
illustrate my point.

I don't recall the exact details, but a few months ago I was writing a
small patch for a Haskell project I liked. Datatypes were simple, e.g.:

    data SomeData = SomeData {
        somedataName :: String
      , somedataVersion :: Int
      , somedataSynopsis :: Maybe String
      , somedataDescription :: Maybe String
      , somedataHomepage :: Maybe String
      , somedataBugReports :: Maybe String
      -- etc, etc.

In the where part of the (long) top level function, I found an
expression similar to this:

    -- there was no type sig there
    alfa = ("version", somedataVersion)

A tuple with a String and an accessor `SomeData -> Int`, ok.
Somewhere else this pops out:

    let beta = 7 + snd alfa

What? For sure something is wrong, this program shouldn't compile! It
should be:

    let beta = 7 + (snd alfa) myData

I fired ghci, loaded the project and it turns out I was right and ghc wrong!

    ?> :t ("s", somedataVersion)
    ("s", somedataVersion) :: (String , SomeData -> Int)

What was happening? A conspicuous bug in ghc (which was exploited in
a weird way by the project developer)? Hallucinations? Not really!
It turns out that in the top of the file, which looked like:

    {-# LANGUAGE CPP #-}
    {-# LANGUAGE OverloadedStrings #-}
    {-# LANGUAGE QuasiQuotes #-}
    {-# LANGUAGE RecordWildCards #-}
    {-# LANGUAGE ViewPatterns #-}

I missed the `RecordWildCards` extension. RecordWildCards allows these
kind of patterns:

    f (C {a = 1, ..}) = b + c + d
        -- shame on me for not checking extensions first!

This long introduction to make my point :P

> It seems to me that lately the community?s visible attitude has
> shifted toward a heightened value of stability and uniformity for
> Haskell and its software ecosystem, and experimentation, fragmentation
> and diversity in styles and dialects are now viewed as threatening.
> This drives us to reject the process of gradual improvement that has
> made Haskell great over the years.

Even though they aren't as 'dangerous' as other well known extensions,
5 small syntactic extensions potentially create 31 dialects which will
make me trip in many different ways. One of the reason I like Haskell is
because it's a joy to read other people's code (unlike other languages
where I don't even try, so daunting is the challenge).

I think it is healthy to have a thorough discussion for each one of the
proposed extensions and most importantly study what we are trying to
accomplish and see if there is a way to reach the same goal(s) with a
smaller set of orthogonal changes.
And yes, to err on the conservative side and say 'no' if the benefit
isn't worth the additional fragmentation.

I understand the fact that Haskell is meant to be an always evolving
language: this is awesome and I like it. I like it even more when
the community goes forward *together*! [1]


Sorry for the long rant (phew, it took more words than necessary)!
As written above, your message cleared my mind so I decided to share my
thoughts, maybe they can be helpful to the discussion.


[1] be it a Standard like H2010, a well thought out migration-path
    for changes like BPP, a stricter and curated selection for
    extensions, etc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/5edccc60/attachment-0001.sig>

From tikhon at jelv.is  Sun Sep  6 23:43:57 2015
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Sun, 6 Sep 2015 16:43:57 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <20150906220854.GA16322@casa.casa>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <CAJWnFaO59nqeNacmZTuMZO=K+oVf=nR8i=En4v65hDBk0f4U9A@mail.gmail.com>
 <20150906220854.GA16322@casa.casa>
Message-ID: <CAJN5CVJAxqPPY3EqvyfXwozRdEPXrctTZQYXeVHQp4wdde+qjg@mail.gmail.com>

+1 from me. At a high level, one of the things that attracts me to Haskell
over other languages is that it's willing to change and improve at a faster
rate (although, in absolute terms, it's still pretty slow and concerned
about backwards compatibility). Assuming a tweak makes sense, rolling it
out as an extension and then folding it into the language (maybe as part of
the mythical Haskell 2020 standard :)) is perfect. DoAndIfThenElse is a
reasonable point of comparison and seems to be a good deal.

And I *do* think this tweak makes sense. The new behavior is more inline
with my expectations. I feel that do and lambdas are self-contained
expressions and inherently group their contents together; needing an extra
set of parentheses or a $ does not make sense. A good way to think about it
is that I see do as having braces semantically even when they're
syntactically optional. I think most people would agree that requiring
parentheses aroud

    foo (do { x; y; z })

is redundant and not useful.

However, I would feel even better if this applied evenly to *all* syntactic
elements that worked this way including case expressions. Were they left
out just to make the proposal simpler? If you could change the grammar to
support this for all the relevant syntactic constructions and it worked
reasonably well, I would be significantly more enthusiastic about it. That
would feel like a significant simplification of the syntax.

Also, it's worth noting that, as somebody pointed out in the Reddit thread,
this extension would make the impredicativity magic around $ less
necessary, which feels like a pointer that it *is* a simpler design.

On Sun, Sep 6, 2015 at 3:08 PM, Francesco Ariis <fa-ml at ariis.it> wrote:

> On Sun, Sep 06, 2015 at 02:33:28PM -0430, Manuel G?mez wrote:
> > It seems to me that lately the community?s visible attitude has
> > shifted toward a heightened value of stability and uniformity for
> > Haskell and its software ecosystem, and experimentation, fragmentation
> > and diversity in styles and dialects are now viewed as threatening.
> > This drives us to reject the process of gradual improvement that has
> > made Haskell great over the years.  Other similarly purely syntactic
> > extensions seem to me to have been met with less resistance in the
> > past.  It appears we?re now far more concerned with the pursuit of
> > success.
> >
> > +1
>
> Hello Manuel,
>     your post made me clearly realise why I am sometimes unhappy about
> syntactic extensions, so I'll take advantage of this discussion to
> illustrate my point.
>
> I don't recall the exact details, but a few months ago I was writing a
> small patch for a Haskell project I liked. Datatypes were simple, e.g.:
>
>     data SomeData = SomeData {
>         somedataName :: String
>       , somedataVersion :: Int
>       , somedataSynopsis :: Maybe String
>       , somedataDescription :: Maybe String
>       , somedataHomepage :: Maybe String
>       , somedataBugReports :: Maybe String
>       -- etc, etc.
>
> In the where part of the (long) top level function, I found an
> expression similar to this:
>
>     -- there was no type sig there
>     alfa = ("version", somedataVersion)
>
> A tuple with a String and an accessor `SomeData -> Int`, ok.
> Somewhere else this pops out:
>
>     let beta = 7 + snd alfa
>
> What? For sure something is wrong, this program shouldn't compile! It
> should be:
>
>     let beta = 7 + (snd alfa) myData
>
> I fired ghci, loaded the project and it turns out I was right and ghc
> wrong!
>
>     ?> :t ("s", somedataVersion)
>     ("s", somedataVersion) :: (String , SomeData -> Int)
>
> What was happening? A conspicuous bug in ghc (which was exploited in
> a weird way by the project developer)? Hallucinations? Not really!
> It turns out that in the top of the file, which looked like:
>
>     {-# LANGUAGE CPP #-}
>     {-# LANGUAGE OverloadedStrings #-}
>     {-# LANGUAGE QuasiQuotes #-}
>     {-# LANGUAGE RecordWildCards #-}
>     {-# LANGUAGE ViewPatterns #-}
>
> I missed the `RecordWildCards` extension. RecordWildCards allows these
> kind of patterns:
>
>     f (C {a = 1, ..}) = b + c + d
>         -- shame on me for not checking extensions first!
>
> This long introduction to make my point :P
>
> > It seems to me that lately the community?s visible attitude has
> > shifted toward a heightened value of stability and uniformity for
> > Haskell and its software ecosystem, and experimentation, fragmentation
> > and diversity in styles and dialects are now viewed as threatening.
> > This drives us to reject the process of gradual improvement that has
> > made Haskell great over the years.
>
> Even though they aren't as 'dangerous' as other well known extensions,
> 5 small syntactic extensions potentially create 31 dialects which will
> make me trip in many different ways. One of the reason I like Haskell is
> because it's a joy to read other people's code (unlike other languages
> where I don't even try, so daunting is the challenge).
>
> I think it is healthy to have a thorough discussion for each one of the
> proposed extensions and most importantly study what we are trying to
> accomplish and see if there is a way to reach the same goal(s) with a
> smaller set of orthogonal changes.
> And yes, to err on the conservative side and say 'no' if the benefit
> isn't worth the additional fragmentation.
>
> I understand the fact that Haskell is meant to be an always evolving
> language: this is awesome and I like it. I like it even more when
> the community goes forward *together*! [1]
>
>
> Sorry for the long rant (phew, it took more words than necessary)!
> As written above, your message cleared my mind so I decided to share my
> thoughts, maybe they can be helpful to the discussion.
>
>
> [1] be it a Standard like H2010, a well thought out migration-path
>     for changes like BPP, a stricter and curated selection for
>     extensions, etc.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150906/027c4795/attachment.html>

From dasuraga at gmail.com  Mon Sep  7 01:39:28 2015
From: dasuraga at gmail.com (Raphael Gaschignard)
Date: Mon, 07 Sep 2015 01:39:28 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJN5CVJAxqPPY3EqvyfXwozRdEPXrctTZQYXeVHQp4wdde+qjg@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <CAJWnFaO59nqeNacmZTuMZO=K+oVf=nR8i=En4v65hDBk0f4U9A@mail.gmail.com>
 <20150906220854.GA16322@casa.casa>
 <CAJN5CVJAxqPPY3EqvyfXwozRdEPXrctTZQYXeVHQp4wdde+qjg@mail.gmail.com>
Message-ID: <CAAd0ehWgAmdG12nr_iBuNnmSEBm=mAn82nzjy1uV_Z2ngygqWA@mail.gmail.com>

I'm coming from a less-informed background than most people, but isn't the
fact that we need parentheses in the first place a bit odd?

  If Haskell's grammar went something like expression := (literal+) |
doBlock, wouldn't the presence of the `do` keyword be enough for the parser
to acknowledge the presence of a do block, and use the curly brackets
inserted by the indent parser step to denote where the expression ends? In
that case , it seems like that would solve the need for the $ issue, and
make the parser simpler...

  Apologies if this is what's actually happening in this extension, but
most people against this extension seem to say that it adds complexity.
Could someone point out how things end up being more complex?

   My impression is that in the current state there's a difference in
treatment between a do block and other expressions that is more complex
than it should be.



On Mon, Sep 7, 2015 at 8:44 AM Tikhon Jelvis <tikhon at jelv.is> wrote:

> +1 from me. At a high level, one of the things that attracts me to Haskell
> over other languages is that it's willing to change and improve at a faster
> rate (although, in absolute terms, it's still pretty slow and concerned
> about backwards compatibility). Assuming a tweak makes sense, rolling it
> out as an extension and then folding it into the language (maybe as part of
> the mythical Haskell 2020 standard :)) is perfect. DoAndIfThenElse is a
> reasonable point of comparison and seems to be a good deal.
>
> And I *do* think this tweak makes sense. The new behavior is more inline
> with my expectations. I feel that do and lambdas are self-contained
> expressions and inherently group their contents together; needing an extra
> set of parentheses or a $ does not make sense. A good way to think about it
> is that I see do as having braces semantically even when they're
> syntactically optional. I think most people would agree that requiring
> parentheses aroud
>
>     foo (do { x; y; z })
>
> is redundant and not useful.
>
> However, I would feel even better if this applied evenly to *all*
> syntactic elements that worked this way including case expressions. Were
> they left out just to make the proposal simpler? If you could change the
> grammar to support this for all the relevant syntactic constructions and it
> worked reasonably well, I would be significantly more enthusiastic about
> it. That would feel like a significant simplification of the syntax.
>
> Also, it's worth noting that, as somebody pointed out in the Reddit
> thread, this extension would make the impredicativity magic around $ less
> necessary, which feels like a pointer that it *is* a simpler design.
>
> On Sun, Sep 6, 2015 at 3:08 PM, Francesco Ariis <fa-ml at ariis.it> wrote:
>
>> On Sun, Sep 06, 2015 at 02:33:28PM -0430, Manuel G?mez wrote:
>> > It seems to me that lately the community?s visible attitude has
>> > shifted toward a heightened value of stability and uniformity for
>> > Haskell and its software ecosystem, and experimentation, fragmentation
>> > and diversity in styles and dialects are now viewed as threatening.
>> > This drives us to reject the process of gradual improvement that has
>> > made Haskell great over the years.  Other similarly purely syntactic
>> > extensions seem to me to have been met with less resistance in the
>> > past.  It appears we?re now far more concerned with the pursuit of
>> > success.
>> >
>> > +1
>>
>> Hello Manuel,
>>     your post made me clearly realise why I am sometimes unhappy about
>> syntactic extensions, so I'll take advantage of this discussion to
>> illustrate my point.
>>
>> I don't recall the exact details, but a few months ago I was writing a
>> small patch for a Haskell project I liked. Datatypes were simple, e.g.:
>>
>>     data SomeData = SomeData {
>>         somedataName :: String
>>       , somedataVersion :: Int
>>       , somedataSynopsis :: Maybe String
>>       , somedataDescription :: Maybe String
>>       , somedataHomepage :: Maybe String
>>       , somedataBugReports :: Maybe String
>>       -- etc, etc.
>>
>> In the where part of the (long) top level function, I found an
>> expression similar to this:
>>
>>     -- there was no type sig there
>>     alfa = ("version", somedataVersion)
>>
>> A tuple with a String and an accessor `SomeData -> Int`, ok.
>> Somewhere else this pops out:
>>
>>     let beta = 7 + snd alfa
>>
>> What? For sure something is wrong, this program shouldn't compile! It
>> should be:
>>
>>     let beta = 7 + (snd alfa) myData
>>
>> I fired ghci, loaded the project and it turns out I was right and ghc
>> wrong!
>>
>>     ?> :t ("s", somedataVersion)
>>     ("s", somedataVersion) :: (String , SomeData -> Int)
>>
>> What was happening? A conspicuous bug in ghc (which was exploited in
>> a weird way by the project developer)? Hallucinations? Not really!
>> It turns out that in the top of the file, which looked like:
>>
>>     {-# LANGUAGE CPP #-}
>>     {-# LANGUAGE OverloadedStrings #-}
>>     {-# LANGUAGE QuasiQuotes #-}
>>     {-# LANGUAGE RecordWildCards #-}
>>     {-# LANGUAGE ViewPatterns #-}
>>
>> I missed the `RecordWildCards` extension. RecordWildCards allows these
>> kind of patterns:
>>
>>     f (C {a = 1, ..}) = b + c + d
>>         -- shame on me for not checking extensions first!
>>
>> This long introduction to make my point :P
>>
>> > It seems to me that lately the community?s visible attitude has
>> > shifted toward a heightened value of stability and uniformity for
>> > Haskell and its software ecosystem, and experimentation, fragmentation
>> > and diversity in styles and dialects are now viewed as threatening.
>> > This drives us to reject the process of gradual improvement that has
>> > made Haskell great over the years.
>>
>> Even though they aren't as 'dangerous' as other well known extensions,
>> 5 small syntactic extensions potentially create 31 dialects which will
>> make me trip in many different ways. One of the reason I like Haskell is
>> because it's a joy to read other people's code (unlike other languages
>> where I don't even try, so daunting is the challenge).
>>
>> I think it is healthy to have a thorough discussion for each one of the
>> proposed extensions and most importantly study what we are trying to
>> accomplish and see if there is a way to reach the same goal(s) with a
>> smaller set of orthogonal changes.
>> And yes, to err on the conservative side and say 'no' if the benefit
>> isn't worth the additional fragmentation.
>>
>> I understand the fact that Haskell is meant to be an always evolving
>> language: this is awesome and I like it. I like it even more when
>> the community goes forward *together*! [1]
>>
>>
>> Sorry for the long rant (phew, it took more words than necessary)!
>> As written above, your message cleared my mind so I decided to share my
>> thoughts, maybe they can be helpful to the discussion.
>>
>>
>> [1] be it a Standard like H2010, a well thought out migration-path
>>     for changes like BPP, a stricter and curated selection for
>>     extensions, etc.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/7f4d845d/attachment.html>

From davidfstr at gmail.com  Mon Sep  7 03:21:16 2015
From: davidfstr at gmail.com (David Foster)
Date: Sun, 06 Sep 2015 20:21:16 -0700
Subject: [Haskell-cafe] I wrote a type checker: ARF. Is it novel?
Message-ID: <55ED02AC.7010109@gmail.com>

I've written a small untyped language calculus (ARF) and an 
interprocedural flow-based type checker to explore techniques for 
efficiently inferring all types in the presence of recursive function 
calls, with no prior type declarations or annotations required in the 
original program.

The type checking algorithm I've come up with appears not only to work 
but also to have good performance: O(m^2) time in the worst case and 
O(m) time in the average case, where m is the number of functions in the 
program.

So the question I'd like to pose to any type system buffs on this list is:
(1) Is such an interprocedural flow-based type checking algorithm with 
that kind of performance likely to be novel?

And if you have some interest and time to actually review the strategy 
and/or implementation of the algorithm at 
<https://github.com/davidfstr/arf#assign-recurse-flow-arf>, I'd love to 
know:
(2) Are there similar type checking algorithms that already exist in the 
academic literature?

I'm posting these questions here because I'm guessing that a number of 
folk that work with type systems and type checkers are likely to be 
subscribed to this list. If there are other more-appropriate venues, I'd 
love to hear about about them as well.

-- 
David Foster

From ky3 at atamo.com  Mon Sep  7 03:28:38 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Mon, 7 Sep 2015 10:28:38 +0700
Subject: [Haskell-cafe] I wrote a type checker: ARF. Is it novel?
In-Reply-To: <55ED02AC.7010109@gmail.com>
References: <55ED02AC.7010109@gmail.com>
Message-ID: <CAPY+ZdSyj8MqO8=zTxdxbzs0wFmSfpVXNsg8NsyD1K1rYPih1Q@mail.gmail.com>

On Mon, Sep 7, 2015 at 10:21 AM, David Foster <davidfstr at gmail.com> wrote:

> I'm posting these questions here because I'm guessing that a number of
> folk that work with type systems and type checkers are likely to be
> subscribed to this list. If there are other more-appropriate venues, I'd
> love to hear about about them as well.



There's also the TYPES mailing list, of which a search should locate as top
result.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/bc48ef6d/attachment.html>

From spam at scientician.net  Mon Sep  7 05:39:19 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 7 Sep 2015 07:39:19 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJN5CVJAxqPPY3EqvyfXwozRdEPXrctTZQYXeVHQp4wdde+qjg@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <CAJWnFaO59nqeNacmZTuMZO=K+oVf=nR8i=En4v65hDBk0f4U9A@mail.gmail.com>
 <20150906220854.GA16322@casa.casa>
 <CAJN5CVJAxqPPY3EqvyfXwozRdEPXrctTZQYXeVHQp4wdde+qjg@mail.gmail.com>
Message-ID: <msj7u7$a4d$1@ger.gmane.org>

(Please don't top-post... and please don't quote all of the previous
message unless you really need to  It breaks the flow of conversation.)

On 09/07/2015 01:43 AM, Tikhon Jelvis wrote:
> +1 from me. At a high level, one of the things that attracts me to Haskell
> over other languages is that it's willing to change and improve at a faster
> rate (although, in absolute terms, it's still pretty slow and concerned
> about backwards compatibility). Assuming a tweak makes sense, rolling it
> out as an extension and then folding it into the language (maybe as part of
> the mythical Haskell 2020 standard :)) is perfect. DoAndIfThenElse is a
> reasonable point of comparison and seems to be a good deal.

Haskell keeps evolving at a brisk pace, see the depenently typed stuff
that's coming up, etc.

I question the value of constantly changing the *syntax*, which is
mostly a triviality. The other syntactic extensions that we brought up
saved a lot more than one character, btw!

> 
> And I *do* think this tweak makes sense. The new behavior is more inline
> with my expectations. I feel that do and lambdas are self-contained
> expressions and inherently group their contents together; needing an extra
> set of parentheses or a $ does not make sense. A good way to think about it
> is that I see do as having braces semantically even when they're
> syntactically optional. I think most people would agree that requiring
> parentheses aroud
> 
>     foo (do { x; y; z })
> 
> is redundant and not useful.
> 

So what would you write if foo were changed to take two arguments?

      foo (do { x; y; z }) (do { a; b; c })

See... no surprises!

Regards,



From cma at bitemyapp.com  Mon Sep  7 06:15:55 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 7 Sep 2015 01:15:55 -0500
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <msgo5g$dub$1@ger.gmane.org>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <msgo5g$dub$1@ger.gmane.org>
Message-ID: <CADnndOr=2f4=o5qMZO_xy1ZPyHbY0=kZcvGLT9jfDCuo8yHdJA@mail.gmail.com>

-1

This is additional arbitrariness in the syntax for little gain and will not
make anything more approachable for new people.

On Sun, Sep 6, 2015 at 1:57 AM, Bardur Arantsson <spam at scientician.net>
wrote:

> On 09/06/2015 12:55 AM, Andrew Gibiansky wrote:
> > I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> > `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> > the following code:
> >
>
> -1, too little gain for Yet Another Extension.
>
> It also reduces "regularity".
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/2dd1bad0/attachment.html>

From nicola.gigante at gmail.com  Mon Sep  7 06:33:25 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Mon, 7 Sep 2015 08:33:25 +0200
Subject: [Haskell-cafe] Functional counterpart of counting-sort?
In-Reply-To: <20150906173636.GK14413@weber>
References: <853881CA-AAAA-414F-A34D-4C6B8CB55E24@gmail.com>
 <20150906173636.GK14413@weber>
Message-ID: <5763C5DB-3285-4373-96E7-DB952F935A10@gmail.com>

Il giorno 06/set/2015, alle ore 19:36, Tom Ellis <tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> ha scritto:
> 
>> On Sun, Sep 06, 2015 at 07:29:23PM +0200, Nicola Gigante wrote:
>> Do any of you know if it is possible to sort a _list_ of integers in
>> O(n) time in a (lazy) purely functional language?
> 
> Are you familiar with discrimination?
> 
>    http://hackage.haskell.org/package/discrimination
> 

Well, no, I wasn't aware of it at all! Thank you!

It seems what I'm looking for!
I'll read the papers pointed in the doc, but does anyone have a few 
words to say on what "discrimination" is all about?

Greetings,
Nicola

From sergey.bushnyak at sigrlami.eu  Mon Sep  7 07:17:13 2015
From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak)
Date: Mon, 7 Sep 2015 10:17:13 +0300
Subject: [Haskell-cafe] Can #Haskell be used to generate the #Java class
 libraries relatively error free? #Java8u60
In-Reply-To: <CAMLKXynUVei6vgwK3JjEYP_UmW9By3i6MKtZhyUr+ifooZmjrA@mail.gmail.com>
References: <CAMLKXynUVei6vgwK3JjEYP_UmW9By3i6MKtZhyUr+ifooZmjrA@mail.gmail.com>
Message-ID: <55ED39F9.60609@sigrlami.eu>

Haskell as general purpose language can do mostly any task. Could you 
elaborate more, what kind of JCL you need to generate and what kind of 
errors you might encounter?

On 09/06/2015 11:32 PM, KC wrote:
> Can #Haskell be used to generate the #Java class libraries relatively 
> error free? #Java8u60 


From lambda.fairy at gmail.com  Mon Sep  7 07:37:24 2015
From: lambda.fairy at gmail.com (Chris Wong)
Date: Mon, 7 Sep 2015 19:37:24 +1200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <CANQO64KtfyH+woigo5HTsKEjJxiwYkdg=E=dy7tfAwiiN3GM3g@mail.gmail.com>

+1

One aspect, which I don't think has been brought up yet, is the
consistency with record syntax.

This is a valid Haskell expression:

    someFunction Record { field = 42 }

so it should make sense for this to be valid as well:

    someFunction do foo; bar


On Sun, Sep 6, 2015 at 10:55 AM, Andrew Gibiansky
<andrew.gibiansky at gmail.com> wrote:
> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> `ArgumentBody` is a simple syntax extension, than, when enabled, permits the
> following code:
>
> main = when True do
>   putStrLn "Hello!"
>
>
> main = forM values \value ->
>   print value
>
>
> main = forM values \case
>     Just x -> print x
>     Nothing -> print y
>
>
> In this code we do not need `$` before `do`, lambda, or lambda-case (if
> -XLambdaCase is enabled). This change would not extend to `let`, `if`,
> `case`, or any other constructs.
>
> Pros:
>
> 1. Code is simpler and it greatly reduces the need for "operator line noise"
> of $ everywhere.
> 2. We can avoid using the type-checker hack for $ for things such as runSt.
>
> Cons:
>
> 1. Adds complexity to the compiler. (NB: The change is minimal and not
> invasive at all.)
> 2. Contributes to a proliferation of extensions that other tools must
> support.  (NB: This is just a parser change so should be easy for all tools
> to support.)
>
> I'm very interested in hearing both favoring and dissenting opinions on this
> proposed change. If this change is approved of, names besides -XArgumentBody
> can be considered.
>
> See more info on Trac.
>
> -- Andrew Gibiansky
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Wong (https://lambda.xyz)

"I fear that Haskell is doomed to succeed."
    -- Tony Hoare

From svenpanne at gmail.com  Mon Sep  7 07:53:44 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 7 Sep 2015 09:53:44 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <msj7u7$a4d$1@ger.gmane.org>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <CAJWnFaO59nqeNacmZTuMZO=K+oVf=nR8i=En4v65hDBk0f4U9A@mail.gmail.com>
 <20150906220854.GA16322@casa.casa>
 <CAJN5CVJAxqPPY3EqvyfXwozRdEPXrctTZQYXeVHQp4wdde+qjg@mail.gmail.com>
 <msj7u7$a4d$1@ger.gmane.org>
Message-ID: <CANBN=mtOUZJ1J3Yd9DZiDfP+qJZHWw453nAUi4VFtzgMeyBdoQ@mail.gmail.com>

2015-09-07 7:39 GMT+02:00 Bardur Arantsson <spam at scientician.net>:

> (Please don't top-post... and please don't quote all of the previous
> message unless you really need to  It breaks the flow of conversation.)
>

That's the bane of almost all new mail clients, having the totally wrong
defaults, promoting threads of quadratic size, all in Yoda-style... :-P


> Haskell keeps evolving at a brisk pace, see the depenently typed stuff
> that's coming up, etc.
>

Exactly, and let's not forget all the library-related changes (AMP,
FTP/BBP, MonadFail, SemiGroup/Monoid, etc.): As much as the concrete
syntax, the standard libraries constitute the basis of a common language.
Given the already high velocity of changes in the libraries, let's no make
things more complicated by introducing tons of ad hoc changes for no real
value. Don't get me wrong, the library changes are really valuable and
urgently needed, but they already put some non-trivial burden onto
maintainers. Nevertheless, I'd like to see more cleanup/fixes in that area
(e.g. an overhaul of Num and friends), but this would be item 0 in
https://wiki.haskell.org/Wadler's_Law... ;-)


> I question the value of constantly changing the *syntax*, which is
> mostly a triviality. The other syntactic extensions that we brought up
> saved a lot more than one character, btw!
>

IMHO it's not so much about saving characters, but more about generality
and regularity: One can see e.g. LambdaCase as unification of, well, lambda
and case, making them effectively just syntactic sugar. So by this
reasoning, LambdaCase is a "good" extension. DoAndIfThenElse has a
different quality: It just removes a very common pitfall, so personally I
consider it "less good" than LambdaCase, but it still has some value. The
proposed extension neither generalizes things nor does it remove a common
pitfall => -1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/5eeec41a/attachment.html>

From xiut.xu at gmail.com  Mon Sep  7 08:02:15 2015
From: xiut.xu at gmail.com (xu xiut)
Date: Mon, 7 Sep 2015 04:02:15 -0400
Subject: [Haskell-cafe] cabal or stack command to fetch and add dependency
	to .cabal file
Message-ID: <CANVqfJFCC=KrdnD0=rQbBASv4Tc24+QJ3yCtGvYyQaxFDV7CEQ@mail.gmail.com>

With node.js, you can run `npm install --save package at 1.01`, and that
version of the package will be retrieved and added to your list of
dependencies. If you leave off the version number, it will retrieve the
latest version from a default repository of packages.

Are there any plans to add something this to either cabal or stack?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/cd49708b/attachment.html>

From michael at snoyman.com  Mon Sep  7 08:05:44 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 7 Sep 2015 11:05:44 +0300
Subject: [Haskell-cafe] cabal or stack command to fetch and add
 dependency to .cabal file
In-Reply-To: <CANVqfJFCC=KrdnD0=rQbBASv4Tc24+QJ3yCtGvYyQaxFDV7CEQ@mail.gmail.com>
References: <CANVqfJFCC=KrdnD0=rQbBASv4Tc24+QJ3yCtGvYyQaxFDV7CEQ@mail.gmail.com>
Message-ID: <CAKA2Jg+Tmf4ZVH0pO3aeGAkMvEZcRu9bqM+2ZgCE+Z4Wrwboww@mail.gmail.com>

Yes, stack has plans for automatic stack.yaml maintenance:

https://github.com/commercialhaskell/stack/issues/115

It's been purposely back-burnered as we focus on more central features
first, but it's actually a pretty good issue for a newcomer to embark on
since it doesn't interact with the rest of the system too much.

I'm not exactly sure though what you mean by "fetch" here. To clarify:
stack will automatically download the source for the dependency when
building.

On Mon, Sep 7, 2015 at 11:02 AM, xu xiut <xiut.xu at gmail.com> wrote:

> With node.js, you can run `npm install --save package at 1.01`, and that
> version of the package will be retrieved and added to your list of
> dependencies. If you leave off the version number, it will retrieve the
> latest version from a default repository of packages.
>
> Are there any plans to add something this to either cabal or stack?
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/297de35c/attachment.html>

From sergey.bushnyak at sigrlami.eu  Mon Sep  7 08:19:03 2015
From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak)
Date: Mon, 7 Sep 2015 11:19:03 +0300
Subject: [Haskell-cafe] cabal or stack command to fetch and add
 dependency to .cabal file
In-Reply-To: <CANVqfJFCC=KrdnD0=rQbBASv4Tc24+QJ3yCtGvYyQaxFDV7CEQ@mail.gmail.com>
References: <CANVqfJFCC=KrdnD0=rQbBASv4Tc24+QJ3yCtGvYyQaxFDV7CEQ@mail.gmail.com>
Message-ID: <55ED4877.9060407@sigrlami.eu>

Cabal already have this feature with `cabal install package-0.1.1.0 `

On 09/07/2015 11:02 AM, xu xiut wrote:
> Are there any plans to add something this to either cabal or stack?


From sergey.bushnyak at sigrlami.eu  Mon Sep  7 08:24:56 2015
From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak)
Date: Mon, 7 Sep 2015 11:24:56 +0300
Subject: [Haskell-cafe] cabal or stack command to fetch and add
 dependency to .cabal file
In-Reply-To: <55ED4877.9060407@sigrlami.eu>
References: <CANVqfJFCC=KrdnD0=rQbBASv4Tc24+QJ3yCtGvYyQaxFDV7CEQ@mail.gmail.com>
 <55ED4877.9060407@sigrlami.eu>
Message-ID: <55ED49D8.7060401@sigrlami.eu>

> added to your list of dependencies
Sorry, lost that part, you still will need to update your .cabal 
manually with specified version.

Better aim for `stack` nowadays, it's much easier to maintain working 
environment.

From K.Bleijenberg at lijbrandt.nl  Mon Sep  7 10:04:55 2015
From: K.Bleijenberg at lijbrandt.nl (Kees Bleijenberg)
Date: Mon, 7 Sep 2015 12:04:55 +0200
Subject: [Haskell-cafe] Conduit and foldLines
Message-ID: <000001d0e954$a5389d60$efa9d820$@lijbrandt.nl>

My  goal is to parse a big text-file line by line using the same parser for
every line.

I am new to Conduit and I've read this
https://www.fpcomplete.com/user/chad/snippets/random-code-snippets/folding-l
ines-in-conduit  article.

 

After adding import  Control.Monad.Trans.Resource for runResourceT and
adding rankNTypes, I got it working. 

Code in www.tbsoftware.nl/TestConduit/TestConduit7.hs

 

I don't understand what is going on in myFunc. Does CL.fold fold over the
already read lines? 

I wonder whether CL.fold loads the whole file in memory?

 

if I change 

            count <- CL.fold (\count t -> count + T.length t) 0 to

            count <- CL.fold (\count t -> T.length t) 0         

nothing changes in the output.  If count is always zero, why using a fold?

 

How can I get the 'current line' in myFunc? 

 

Kees

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/d6467209/attachment.html>

From michael at snoyman.com  Mon Sep  7 10:07:48 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 7 Sep 2015 13:07:48 +0300
Subject: [Haskell-cafe] Conduit and foldLines
In-Reply-To: <000001d0e954$a5389d60$efa9d820$@lijbrandt.nl>
References: <000001d0e954$a5389d60$efa9d820$@lijbrandt.nl>
Message-ID: <CAKA2JgKvrzE64DZZ9LL3Qp76zpjShbYB8fT3QnzqmK=cKWhoJA@mail.gmail.com>

My guess is that your lines are small enough that they always end up in a
single chunk, and therefore you're essentially folding over a list of
length 1.

I'm confused about your question though: isn't `number` the current line?

On Mon, Sep 7, 2015 at 1:04 PM, Kees Bleijenberg <K.Bleijenberg at lijbrandt.nl
> wrote:

> My  goal is to parse a big text-file line by line using the same parser
> for every line.
>
> I am new to Conduit and I?ve read this
> https://www.fpcomplete.com/user/chad/snippets/random-code-snippets/folding-lines-in-conduit
>  article.
>
>
>
> After adding import  Control.Monad.Trans.Resource for runResourceT and
> adding rankNTypes, I got it working.
>
> Code in www.tbsoftware.nl/TestConduit/TestConduit7.hs
>
>
>
> I don't understand what is going on in myFunc. Does CL.fold fold over the
> already read lines?
>
> I wonder whether CL.fold loads the whole file in memory?
>
>
>
> if I change
>
>             count <- CL.fold (\count t -> count + T.length t) 0 to
>
>             count <- CL.fold (\count t -> T.length t) 0
>
> nothing changes in the output.  If count is always zero, why using a fold?
>
>
>
> How can I get the ?current line? in myFunc?
>
>
>
> Kees
>
>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/94b3dc6f/attachment.html>

From mail at joachim-breitner.de  Mon Sep  7 12:10:27 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 07 Sep 2015 14:10:27 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
Message-ID: <1441627827.1570.31.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
> 3. It does make some cases cleaner. Consider the following code: [1,
> 2, 3] ++ concat (do { .... }). This can be written with parentheses, 
> bit it cannot be written with $, because [1, 2, 3] ++ concat $ do { 
> .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is 
> sometimes annoying behaviour. (I used the list monad here just for 
> demo purposes. I find it is more common with applicative operators.) 

good point! This has bitten me before.

I believe that the language would be better with the proposed syntax
change being the default. So the way forward is to indeed add this
extension, see how people use it, and if Haskell' ever goes somewhere,
it might include this as the default ? all alike to DoAndIfThenElse.

Also note that this does not change the meaning of any existing
program, AFAIK. So it is not that you might be reading existing code
wrongly if you are not aware that this extension is being used; you
will just find code that looks like invalid syntax to you ? until you
check the list of extensions (or just deduce that ArgumentBlock is used
here).

Therefore, +1 from me.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/a6b68f8e/attachment.sig>

From rnmss.hs at gmail.com  Mon Sep  7 14:08:26 2015
From: rnmss.hs at gmail.com (DreamApart AtHaskells)
Date: Mon, 7 Sep 2015 22:08:26 +0800
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
Message-ID: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>

The class Num defines the method functions like (+), (-), (*), negate, ...
But they are actually different concepts.

We often meet situations that we want an addition for some type, but
not a multiplication. For example:

    *data* Vec3 = Vec3 Float Float Float

The additive (and subtractive) operation is obvious, but not for a
multiplication.

*  Note*

    (*) :: a -> a -> a   -- not avaliable for a Vec3

    scale :: Float -> Vec3 -> Vec3
    dot :: Vec3 -> Vec3 -> Float

We cannot define a (+) alone for a type, so we got many different functions
from different libs, like mappend, mplus, plus, (<+>), (.+.), (+.), which
all reads
"plus".

My opinion is that the methods of Num should be seperated into different
type
classes, so we don't need to invent a new symbol for a new lib.

A feasible design is:

    *import* Prelude *hiding* ( Num (..), Monoid (..), sum )

    *class* SemiGroup a *where*
        (+)         :: a -> a -> a

    *class* SemiGroup a => Monoid a *where*
        zero        :: a

    *class* Monoid a => Group a *where*
        negate      :: a -> a
        (-)         :: a -> a -> a

        x - y    = x + negate y
        negate x = zero - x

    *class* Group a => Ring a *where   *-- not sure about the name ...
        (*)         :: a -> a -> a

    *class* Ring a => Num a *where*
        abs         :: a -> a
        signum      :: a -> a
        fromInteger :: Integer -> a

    sum :: (Foldable t, Monoid a) => t a -> a
    sum = foldl' (+) zero

    -- for compatibility
    mempty = zero
    mappend = (+)
    mconcat = sum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/a673c05e/attachment.html>

From rnmss.hs at gmail.com  Mon Sep  7 14:13:03 2015
From: rnmss.hs at gmail.com (DreamApart AtHaskells)
Date: Mon, 7 Sep 2015 22:13:03 +0800
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
Message-ID: <CANNywisS3NMQQ2JJUMTD0E_Dz8GseCkVcQ9x-HkErkjx03s8KQ@mail.gmail.com>

?sorry, didn't realize?
?
? the subjects? prefixed with a "[Haskell-Cafe]"



2015-09-07 22:08 GMT+08:00 DreamApart AtHaskells <rnmss.hs at gmail.com>:

> The class Num defines the method functions like (+), (-), (*), negate, ...
> But they are actually different concepts.
>
> We often meet situations that we want an addition for some type, but
> not a multiplication. For example:
>
>     *data* Vec3 = Vec3 Float Float Float
>
> The additive (and subtractive) operation is obvious, but not for a
> multiplication.
>
> *  Note*
>
>     (*) :: a -> a -> a   -- not avaliable for a Vec3
>
>     scale :: Float -> Vec3 -> Vec3
>     dot :: Vec3 -> Vec3 -> Float
>
> We cannot define a (+) alone for a type, so we got many different
> functions
> from different libs, like mappend, mplus, plus, (<+>), (.+.), (+.), which
> all reads
> "plus".
>
> My opinion is that the methods of Num should be seperated into different
> type
> classes, so we don't need to invent a new symbol for a new lib.
>
> A feasible design is:
>
>     *import* Prelude *hiding* ( Num (..), Monoid (..), sum )
>
>     *class* SemiGroup a *where*
>         (+)         :: a -> a -> a
>
>     *class* SemiGroup a => Monoid a *where*
>         zero        :: a
>
>     *class* Monoid a => Group a *where*
>         negate      :: a -> a
>         (-)         :: a -> a -> a
>
>         x - y    = x + negate y
>         negate x = zero - x
>
>     *class* Group a => Ring a *where   *-- not sure about the name ...
>         (*)         :: a -> a -> a
>
>     *class* Ring a => Num a *where*
>         abs         :: a -> a
>         signum      :: a -> a
>         fromInteger :: Integer -> a
>
>     sum :: (Foldable t, Monoid a) => t a -> a
>     sum = foldl' (+) zero
>
>     -- for compatibility
>     mempty = zero
>     mappend = (+)
>     mconcat = sum
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/fdb59ac5/attachment.html>

From allbery.b at gmail.com  Mon Sep  7 14:47:46 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 7 Sep 2015 10:47:46 -0400
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
Message-ID: <CAKFCL4XyKY_JojPXr2raTuDvwjmb4frnR8_KEbcsTYu5eAfEfA@mail.gmail.com>

On Mon, Sep 7, 2015 at 10:08 AM, DreamApart AtHaskells <rnmss.hs at gmail.com>
wrote:

> The class Num defines the method functions like (+), (-), (*), negate, ...
> But they are actually different concepts.
>
> We often meet situations that we want an addition for some type, but
> not a multiplication. For example:
>

I think the concept you're reaching for here is Monoid. However, there is
a(t least one) complication you did not consider:

(+) is assuredly a monoid.
But so is (*)! (Try looking at it through logarithms.)
Unfortunately, a given type can have only a single instance of a given
typeclass.

There is in fact a way to design Num "rationally", via number theory; I
suggest you at least familiarize yourself with that. (This will bring you
face to face with the above issue, as it turns out that Num requires two
monoids.) It turns out that this is not necessarily a good idea. But see
http://hackage.haskell.org/package/numeric-prelude for an implementation of
it.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/3ed022af/attachment.html>

From allbery.b at gmail.com  Mon Sep  7 15:28:19 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 7 Sep 2015 11:28:19 -0400
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
Message-ID: <CAKFCL4VLkef-1KBOnfQHPW57ipH-at=mh1nWL0wznEyO_Y+OpA@mail.gmail.com>

On Mon, Sep 7, 2015 at 10:08 AM, DreamApart AtHaskells <rnmss.hs at gmail.com>
wrote:

> We cannot define a (+) alone for a type, so we got many different
> functions
> from different libs, like mappend, mplus, plus, (<+>), (.+.), (+.), which
> all reads
> "plus".
>

I should mention one other difficulty: MonadPlus and Monoid are not quite
the same thing. mplus and mappend can't really be unified into a single
conceptual structure (mostly because of the Maybe instance).

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/eb4dd51b/attachment.html>

From andrew.gibiansky at gmail.com  Mon Sep  7 17:57:01 2015
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Mon, 7 Sep 2015 10:57:01 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <1441627827.1570.31.camel@joachim-breitner.de>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
Message-ID: <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>

So, it looks like this extension is quite controversial. To summarize the
main points raised in this discussion:

Pro: (+9)
    - It's easier to read than the alternative.
    - This extension removes syntactic noise.
    - This makes basic do-syntax more approachable to newbies; it is a
commonly asked question as to why the $ is necessary.
    - This simplifies the resulting AST, potentially making it simpler for
editors and other tools to do refactoring.
    - It's something that belongs in the main language, and if its
something we'd consider for a mythical Haskell', it has to start as an
extension.
    - It gets rid of some cases where using $ doesn't work because $
interacts with other infix operators being used in the same expression.
    - This would make do blocks consistent with record creation, where
parentheses are skipped, allowing things such as "return R { x = y}"
    - This does not change the meaning of any old programs, only allows new
ones that were previously forbidden.
    - This gets rid of the need for a specially-typed $ allowing "runSt $
do ..."

Con: (-9)
    - It's harder to read than the alternative.
    - Creating a language extension to get rid of a single character is
overkill and unnecessary.
    - You can already get rid of the $ by just adding parentheses.
    - More and more syntactic "improvements" just fragment the language.
    - Although this is consistent with record syntax, record syntax without
parents was a mistake originally.

Questions:
    - Why doesn't this apply to case, let, if, etc?
    - Should this apply to case, let, if, etc?

I would say people on /r/haskell and haskell-cafe seem fairly evenly split,
perhaps somewhat favoring *not* including this extension.

1. How representative are the opinions expressed through these media of the
general Haskell community? (If one exists...)
2. What, historically, has been the GHC policy on including
questionable/controversial extensions?
3. We do have another option: with the advent of ghc-exactprint, we could
probably write a preprocessor that emulates this extension, parsing as if
ArgumentDo is enabled and then inserting a $ where necessary. This would
allow us to test out this extension without modifying GHC and thus being
stuck with the extension in mainline GHC indefinitely (since, as I
understand it, there's not really a process for *removing* extensions from
GHC).


On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
> > 3. It does make some cases cleaner. Consider the following code: [1,
> > 2, 3] ++ concat (do { .... }). This can be written with parentheses,
> > bit it cannot be written with $, because [1, 2, 3] ++ concat $ do {
> > .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is
> > sometimes annoying behaviour. (I used the list monad here just for
> > demo purposes. I find it is more common with applicative operators.)
>
> good point! This has bitten me before.
>
> I believe that the language would be better with the proposed syntax
> change being the default. So the way forward is to indeed add this
> extension, see how people use it, and if Haskell' ever goes somewhere,
> it might include this as the default ? all alike to DoAndIfThenElse.
>
> Also note that this does not change the meaning of any existing
> program, AFAIK. So it is not that you might be reading existing code
> wrongly if you are not aware that this extension is being used; you
> will just find code that looks like invalid syntax to you ? until you
> check the list of extensions (or just deduce that ArgumentBlock is used
> here).
>
> Therefore, +1 from me.
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/08a86b50/attachment.html>

From ollie at ocharles.org.uk  Mon Sep  7 18:25:58 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Mon, 07 Sep 2015 18:25:58 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
Message-ID: <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>

I don't think you need ghc-exactprint for that - you can just write a GHC
preprocessor, hopefully being able to reuse the current grammar
specification you already have. See the -prgmF option (I think it's called
that, best check the GHC manual). You don't really care about the source
code formatting, because you're going to pass it straight off to the
compiler anyway. Though I guess maybe exactprint could help so error
messages still map cleanly.

On Mon, Sep 7, 2015 at 6:57 PM Andrew Gibiansky <andrew.gibiansky at gmail.com>
wrote:

> So, it looks like this extension is quite controversial. To summarize the
> main points raised in this discussion:
>
> Pro: (+9)
>     - It's easier to read than the alternative.
>     - This extension removes syntactic noise.
>     - This makes basic do-syntax more approachable to newbies; it is a
> commonly asked question as to why the $ is necessary.
>     - This simplifies the resulting AST, potentially making it simpler for
> editors and other tools to do refactoring.
>     - It's something that belongs in the main language, and if its
> something we'd consider for a mythical Haskell', it has to start as an
> extension.
>     - It gets rid of some cases where using $ doesn't work because $
> interacts with other infix operators being used in the same expression.
>     - This would make do blocks consistent with record creation, where
> parentheses are skipped, allowing things such as "return R { x = y}"
>     - This does not change the meaning of any old programs, only allows
> new ones that were previously forbidden.
>     - This gets rid of the need for a specially-typed $ allowing "runSt $
> do ..."
>
> Con: (-9)
>     - It's harder to read than the alternative.
>     - Creating a language extension to get rid of a single character is
> overkill and unnecessary.
>     - You can already get rid of the $ by just adding parentheses.
>     - More and more syntactic "improvements" just fragment the language.
>     - Although this is consistent with record syntax, record syntax
> without parents was a mistake originally.
>
> Questions:
>     - Why doesn't this apply to case, let, if, etc?
>     - Should this apply to case, let, if, etc?
>
> I would say people on /r/haskell and haskell-cafe seem fairly evenly
> split, perhaps somewhat favoring *not* including this extension.
>
> 1. How representative are the opinions expressed through these media of
> the general Haskell community? (If one exists...)
> 2. What, historically, has been the GHC policy on including
> questionable/controversial extensions?
> 3. We do have another option: with the advent of ghc-exactprint, we could
> probably write a preprocessor that emulates this extension, parsing as if
> ArgumentDo is enabled and then inserting a $ where necessary. This would
> allow us to test out this extension without modifying GHC and thus being
> stuck with the extension in mainline GHC indefinitely (since, as I
> understand it, there's not really a process for *removing* extensions from
> GHC).
>
>
> On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner <mail at joachim-breitner.de
> > wrote:
>
>> Hi,
>>
>> Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
>> > 3. It does make some cases cleaner. Consider the following code: [1,
>> > 2, 3] ++ concat (do { .... }). This can be written with parentheses,
>> > bit it cannot be written with $, because [1, 2, 3] ++ concat $ do {
>> > .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is
>> > sometimes annoying behaviour. (I used the list monad here just for
>> > demo purposes. I find it is more common with applicative operators.)
>>
>> good point! This has bitten me before.
>>
>> I believe that the language would be better with the proposed syntax
>> change being the default. So the way forward is to indeed add this
>> extension, see how people use it, and if Haskell' ever goes somewhere,
>> it might include this as the default ? all alike to DoAndIfThenElse.
>>
>> Also note that this does not change the meaning of any existing
>> program, AFAIK. So it is not that you might be reading existing code
>> wrongly if you are not aware that this extension is being used; you
>> will just find code that looks like invalid syntax to you ? until you
>> check the list of extensions (or just deduce that ArgumentBlock is used
>> here).
>>
>> Therefore, +1 from me.
>>
>> Greetings,
>> Joachim
>>
>> --
>> Joachim ?nomeata? Breitner
>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/01b56c69/attachment.html>

From andrew.gibiansky at gmail.com  Mon Sep  7 18:29:34 2015
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Mon, 7 Sep 2015 11:29:34 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
Message-ID: <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>

We would need ghc-exactprint to provide a good source to source
transformation for error messages. Otherwise using this quasi-extension
would be quite problematic in real-world work.

I actually really like this idea -- it would give us a way to experiment
with new syntax easily, including things such as changing `type`, `data`,
`newtype`, and any other syntactic woes we might have about the Haskell
language.

-- Andrew

On Mon, Sep 7, 2015 at 11:25 AM, Oliver Charles <ollie at ocharles.org.uk>
wrote:

> I don't think you need ghc-exactprint for that - you can just write a GHC
> preprocessor, hopefully being able to reuse the current grammar
> specification you already have. See the -prgmF option (I think it's called
> that, best check the GHC manual). You don't really care about the source
> code formatting, because you're going to pass it straight off to the
> compiler anyway. Though I guess maybe exactprint could help so error
> messages still map cleanly.
>
> On Mon, Sep 7, 2015 at 6:57 PM Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> So, it looks like this extension is quite controversial. To summarize the
>> main points raised in this discussion:
>>
>> Pro: (+9)
>>     - It's easier to read than the alternative.
>>     - This extension removes syntactic noise.
>>     - This makes basic do-syntax more approachable to newbies; it is a
>> commonly asked question as to why the $ is necessary.
>>     - This simplifies the resulting AST, potentially making it simpler
>> for editors and other tools to do refactoring.
>>     - It's something that belongs in the main language, and if its
>> something we'd consider for a mythical Haskell', it has to start as an
>> extension.
>>     - It gets rid of some cases where using $ doesn't work because $
>> interacts with other infix operators being used in the same expression.
>>     - This would make do blocks consistent with record creation, where
>> parentheses are skipped, allowing things such as "return R { x = y}"
>>     - This does not change the meaning of any old programs, only allows
>> new ones that were previously forbidden.
>>     - This gets rid of the need for a specially-typed $ allowing "runSt $
>> do ..."
>>
>> Con: (-9)
>>     - It's harder to read than the alternative.
>>     - Creating a language extension to get rid of a single character is
>> overkill and unnecessary.
>>     - You can already get rid of the $ by just adding parentheses.
>>     - More and more syntactic "improvements" just fragment the language.
>>     - Although this is consistent with record syntax, record syntax
>> without parents was a mistake originally.
>>
>> Questions:
>>     - Why doesn't this apply to case, let, if, etc?
>>     - Should this apply to case, let, if, etc?
>>
>> I would say people on /r/haskell and haskell-cafe seem fairly evenly
>> split, perhaps somewhat favoring *not* including this extension.
>>
>> 1. How representative are the opinions expressed through these media of
>> the general Haskell community? (If one exists...)
>> 2. What, historically, has been the GHC policy on including
>> questionable/controversial extensions?
>> 3. We do have another option: with the advent of ghc-exactprint, we could
>> probably write a preprocessor that emulates this extension, parsing as if
>> ArgumentDo is enabled and then inserting a $ where necessary. This would
>> allow us to test out this extension without modifying GHC and thus being
>> stuck with the extension in mainline GHC indefinitely (since, as I
>> understand it, there's not really a process for *removing* extensions from
>> GHC).
>>
>>
>> On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi,
>>>
>>> Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
>>> > 3. It does make some cases cleaner. Consider the following code: [1,
>>> > 2, 3] ++ concat (do { .... }). This can be written with parentheses,
>>> > bit it cannot be written with $, because [1, 2, 3] ++ concat $ do {
>>> > .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is
>>> > sometimes annoying behaviour. (I used the list monad here just for
>>> > demo purposes. I find it is more common with applicative operators.)
>>>
>>> good point! This has bitten me before.
>>>
>>> I believe that the language would be better with the proposed syntax
>>> change being the default. So the way forward is to indeed add this
>>> extension, see how people use it, and if Haskell' ever goes somewhere,
>>> it might include this as the default ? all alike to DoAndIfThenElse.
>>>
>>> Also note that this does not change the meaning of any existing
>>> program, AFAIK. So it is not that you might be reading existing code
>>> wrongly if you are not aware that this extension is being used; you
>>> will just find code that looks like invalid syntax to you ? until you
>>> check the list of extensions (or just deduce that ArgumentBlock is used
>>> here).
>>>
>>> Therefore, +1 from me.
>>>
>>> Greetings,
>>> Joachim
>>>
>>> --
>>> Joachim ?nomeata? Breitner
>>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>>>   Debian Developer: nomeata at debian.org
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/9aa9f13b/attachment.html>

From silvio.frischi at gmail.com  Mon Sep  7 19:49:01 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Mon, 7 Sep 2015 21:49:01 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CAKFCL4XyKY_JojPXr2raTuDvwjmb4frnR8_KEbcsTYu5eAfEfA@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CAKFCL4XyKY_JojPXr2raTuDvwjmb4frnR8_KEbcsTYu5eAfEfA@mail.gmail.com>
Message-ID: <55EDEA2D.9070303@gmail.com>

> (+) is assuredly a monoid.
> But so is (*)! (Try looking at it through logarithms.)
> Unfortunately, a given type can have only a single instance of a given
> typeclass.
> 
> There is in fact a way to design Num "rationally", via number theory; I
> suggest you at least familiarize yourself with that. (This will bring
> you face to face with the above issue, as it turns out that Num requires
> two monoids.) It turns out that this is not necessarily a good idea. But
> see http://hackage.haskell.org/package/numeric-prelude for an
> implementation of it.

Well, at some point you will have to make concessions. I for one, would
love to use (+) without Num or going through an entire semester of
Algebra. And DreamApart's proposal seams a reasonable compromise. I
don't see it being included into base any time soon however, as it would
break an enormous amount of code.

As for the Maybe instances. From afar, if you think of Nothing as 0 and
Just x as (not 0), the Monoid instance looks like (*) and the MonadPlus
instance looks like (+).

Also, I would prefer.

class (Monoid m) => Ring m where
    ...

class (Group a, Ring a) => Num a where
    ...

Cheers

Silvio

From silvio.frischi at gmail.com  Mon Sep  7 19:52:45 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Mon, 7 Sep 2015 21:52:45 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <55EDEA2D.9070303@gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CAKFCL4XyKY_JojPXr2raTuDvwjmb4frnR8_KEbcsTYu5eAfEfA@mail.gmail.com>
 <55EDEA2D.9070303@gmail.com>
Message-ID: <55EDEB0D.8000200@gmail.com>

> class (Monoid m) => Ring m where
>     ...
> 
> class (Group a, Ring a) => Num a where
>     ...

I guess Semiring is the proper name :)

From alexey.muranov at gmail.com  Mon Sep  7 20:05:34 2015
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Mon, 7 Sep 2015 13:05:34 -0700 (PDT)
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
Message-ID: <0387e819-056e-467b-87a2-c9db3963ae18@googlegroups.com>

You saw this, right?

https://wiki.haskell.org/Nitpicks#Base-related_nitpicks

(Just in case, maybe it was you who included this topic.)

Alexey.

On Monday, September 7, 2015 at 4:08:54 PM UTC+2, DreamApart AtHaskells 
wrote:
>
> The class Num defines the method functions like (+), (-), (*), negate, ...
> But they are actually different concepts.
>
> We often meet situations that we want an addition for some type, but
> not a multiplication. For example:
>
>     *data* Vec3 = Vec3 Float Float Float
>
> The additive (and subtractive) operation is obvious, but not for a
> multiplication.
>
> *  Note*
>
>     (*) :: a -> a -> a   -- not avaliable for a Vec3
>
>     scale :: Float -> Vec3 -> Vec3
>     dot :: Vec3 -> Vec3 -> Float
>
> We cannot define a (+) alone for a type, so we got many different 
> functions
> from different libs, like mappend, mplus, plus, (<+>), (.+.), (+.), which 
> all reads
> "plus".
>
> My opinion is that the methods of Num should be seperated into different 
> type
> classes, so we don't need to invent a new symbol for a new lib.
>
> A feasible design is:
>
>     *import* Prelude *hiding* ( Num (..), Monoid (..), sum )
>
>     *class* SemiGroup a *where*
>         (+)         :: a -> a -> a
>
>     *class* SemiGroup a => Monoid a *where*
>         zero        :: a
>     
>     *class* Monoid a => Group a *where*
>         negate      :: a -> a
>         (-)         :: a -> a -> a
>
>         x - y    = x + negate y
>         negate x = zero - x 
>
>     *class* Group a => Ring a *where   *-- not sure about the name ...
>         (*)         :: a -> a -> a
>     
>     *class* Ring a => Num a *where*
>         abs         :: a -> a
>         signum      :: a -> a
>         fromInteger :: Integer -> a
>
>     sum :: (Foldable t, Monoid a) => t a -> a
>     sum = foldl' (+) zero
>
>     -- for compatibility 
>     mempty = zero
>     mappend = (+)
>     mconcat = sum
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/57b373d0/attachment.html>

From silvio.frischi at gmail.com  Mon Sep  7 20:18:50 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Mon, 7 Sep 2015 22:18:50 +0200
Subject: [Haskell-cafe] "Assignment" in do blocks?
In-Reply-To: <CAKit5aAtpV6HLzU-QvjbNk5p+Hib8v_squzHJtB-vN322B+wgw@mail.gmail.com>
References: <CAKit5aD_je06tyG6wQC+zu+EsVa0fmKQPU2YwuRgoGuK8Wk9jQ@mail.gmail.com>
 <CAPY+ZdRf3Toy6dNYhDXF7bTn_pSc7a0pPen2xpX8cWqCqSiRcQ@mail.gmail.com>
 <CAKit5aAtpV6HLzU-QvjbNk5p+Hib8v_squzHJtB-vN322B+wgw@mail.gmail.com>
Message-ID: <55EDF12A.300@gmail.com>

Looking at the nitpick list, I just remembered that there was a
discussion about making let optional in do bindings a couple of years ago.

https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102741.html

One of the major stumbling points was how recursive bindings should
work. These these two proposals would combine nicely.

adding a statement

pat = exp

that expresses a non-recursive let.

Silvio

From danburton.email at gmail.com  Tue Sep  8 01:08:11 2015
From: danburton.email at gmail.com (Dan Burton)
Date: Mon, 7 Sep 2015 18:08:11 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
Message-ID: <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>

+1 people who like it can use it and people who don't like it don't have to
use it. Personally I wish it were the default because the superfluous $
confuses a lot of people coming from other languages like Ruby.

You can even write in the old style if you have the extension turned on. It
doesn't disable the old way of doing things. It just allows a new way. It's
entirely backwards compatible with working code when turned on, is it not?

On Monday, September 7, 2015, Andrew Gibiansky <andrew.gibiansky at gmail.com>
wrote:

> We would need ghc-exactprint to provide a good source to source
> transformation for error messages. Otherwise using this quasi-extension
> would be quite problematic in real-world work.
>
> I actually really like this idea -- it would give us a way to experiment
> with new syntax easily, including things such as changing `type`, `data`,
> `newtype`, and any other syntactic woes we might have about the Haskell
> language.
>
> -- Andrew
>
> On Mon, Sep 7, 2015 at 11:25 AM, Oliver Charles <ollie at ocharles.org.uk
> <javascript:_e(%7B%7D,'cvml','ollie at ocharles.org.uk');>> wrote:
>
>> I don't think you need ghc-exactprint for that - you can just write a GHC
>> preprocessor, hopefully being able to reuse the current grammar
>> specification you already have. See the -prgmF option (I think it's called
>> that, best check the GHC manual). You don't really care about the source
>> code formatting, because you're going to pass it straight off to the
>> compiler anyway. Though I guess maybe exactprint could help so error
>> messages still map cleanly.
>>
>> On Mon, Sep 7, 2015 at 6:57 PM Andrew Gibiansky <
>> andrew.gibiansky at gmail.com
>> <javascript:_e(%7B%7D,'cvml','andrew.gibiansky at gmail.com');>> wrote:
>>
>>> So, it looks like this extension is quite controversial. To summarize
>>> the main points raised in this discussion:
>>>
>>> Pro: (+9)
>>>     - It's easier to read than the alternative.
>>>     - This extension removes syntactic noise.
>>>     - This makes basic do-syntax more approachable to newbies; it is a
>>> commonly asked question as to why the $ is necessary.
>>>     - This simplifies the resulting AST, potentially making it simpler
>>> for editors and other tools to do refactoring.
>>>     - It's something that belongs in the main language, and if its
>>> something we'd consider for a mythical Haskell', it has to start as an
>>> extension.
>>>     - It gets rid of some cases where using $ doesn't work because $
>>> interacts with other infix operators being used in the same expression.
>>>     - This would make do blocks consistent with record creation, where
>>> parentheses are skipped, allowing things such as "return R { x = y}"
>>>     - This does not change the meaning of any old programs, only allows
>>> new ones that were previously forbidden.
>>>     - This gets rid of the need for a specially-typed $ allowing "runSt
>>> $ do ..."
>>>
>>> Con: (-9)
>>>     - It's harder to read than the alternative.
>>>     - Creating a language extension to get rid of a single character is
>>> overkill and unnecessary.
>>>     - You can already get rid of the $ by just adding parentheses.
>>>     - More and more syntactic "improvements" just fragment the language.
>>>     - Although this is consistent with record syntax, record syntax
>>> without parents was a mistake originally.
>>>
>>> Questions:
>>>     - Why doesn't this apply to case, let, if, etc?
>>>     - Should this apply to case, let, if, etc?
>>>
>>> I would say people on /r/haskell and haskell-cafe seem fairly evenly
>>> split, perhaps somewhat favoring *not* including this extension.
>>>
>>> 1. How representative are the opinions expressed through these media of
>>> the general Haskell community? (If one exists...)
>>> 2. What, historically, has been the GHC policy on including
>>> questionable/controversial extensions?
>>> 3. We do have another option: with the advent of ghc-exactprint, we
>>> could probably write a preprocessor that emulates this extension, parsing
>>> as if ArgumentDo is enabled and then inserting a $ where necessary. This
>>> would allow us to test out this extension without modifying GHC and thus
>>> being stuck with the extension in mainline GHC indefinitely (since, as I
>>> understand it, there's not really a process for *removing* extensions from
>>> GHC).
>>>
>>>
>>> On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner <
>>> mail at joachim-breitner.de
>>> <javascript:_e(%7B%7D,'cvml','mail at joachim-breitner.de');>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
>>>> > 3. It does make some cases cleaner. Consider the following code: [1,
>>>> > 2, 3] ++ concat (do { .... }). This can be written with parentheses,
>>>> > bit it cannot be written with $, because [1, 2, 3] ++ concat $ do {
>>>> > .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is
>>>> > sometimes annoying behaviour. (I used the list monad here just for
>>>> > demo purposes. I find it is more common with applicative operators.)
>>>>
>>>> good point! This has bitten me before.
>>>>
>>>> I believe that the language would be better with the proposed syntax
>>>> change being the default. So the way forward is to indeed add this
>>>> extension, see how people use it, and if Haskell' ever goes somewhere,
>>>> it might include this as the default ? all alike to DoAndIfThenElse.
>>>>
>>>> Also note that this does not change the meaning of any existing
>>>> program, AFAIK. So it is not that you might be reading existing code
>>>> wrongly if you are not aware that this extension is being used; you
>>>> will just find code that looks like invalid syntax to you ? until you
>>>> check the list of extensions (or just deduce that ArgumentBlock is used
>>>> here).
>>>>
>>>> Therefore, +1 from me.
>>>>
>>>> Greetings,
>>>> Joachim
>>>>
>>>> --
>>>> Joachim ?nomeata? Breitner
>>>>   mail at joachim-breitner.de
>>>> <javascript:_e(%7B%7D,'cvml','mail at joachim-breitner.de');> ?
>>>> http://www.joachim-breitner.de/
>>>>   Jabber: nomeata at joachim-breitner.de
>>>> <javascript:_e(%7B%7D,'cvml','nomeata at joachim-breitner.de');>  ?
>>>> GPG-Key: 0xF0FBF51F
>>>>   Debian Developer: nomeata at debian.org
>>>> <javascript:_e(%7B%7D,'cvml','nomeata at debian.org');>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> <javascript:_e(%7B%7D,'cvml','Haskell-Cafe at haskell.org');>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> <javascript:_e(%7B%7D,'cvml','Haskell-Cafe at haskell.org');>
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>

-- 
-- Dan Burton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/170f62f0/attachment.html>

From mwm at mired.org  Tue Sep  8 01:15:13 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 08 Sep 2015 01:15:13 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
Message-ID: <CAD=7U2AXYd9YSXCpQrmxdztBptaUZryRGfPFR3puyGM+7NYfSg@mail.gmail.com>

On Mon, Sep 7, 2015 at 8:08 PM Dan Burton <danburton.email at gmail.com> wrote:

> +1 people who like it can use it and people who don't like it don't have
> to use it.
>

Yes, but they still have to be able to read code that uses it, deal with it
in coding standards, deal with how it affects their tool chain, and
otherwise have it affect them.

"If you don't like it, don't use it" is a bogus argument, and should be
shot on sight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/a678cf38/attachment.html>

From ekmett at gmail.com  Tue Sep  8 01:39:30 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 7 Sep 2015 21:39:30 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAD=7U2AXYd9YSXCpQrmxdztBptaUZryRGfPFR3puyGM+7NYfSg@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <CAD=7U2AXYd9YSXCpQrmxdztBptaUZryRGfPFR3puyGM+7NYfSg@mail.gmail.com>
Message-ID: <CAJumaK-ZCPv65qvYxkW0=y2RG0iFhNJGQavNJ-_afeCpcJS_Tw@mail.gmail.com>

Reserving judgment on the merits of the proposal, I would be curious to see
the net impact of such a change on the grammar that GHC parses. How much
changes?

-Edward

On Mon, Sep 7, 2015 at 9:15 PM, Mike Meyer <mwm at mired.org> wrote:

> On Mon, Sep 7, 2015 at 8:08 PM Dan Burton <danburton.email at gmail.com>
> wrote:
>
>> +1 people who like it can use it and people who don't like it don't have
>> to use it.
>>
>
> Yes, but they still have to be able to read code that uses it, deal with
> it in coding standards, deal with how it affects their tool chain, and
> otherwise have it affect them.
>
> "If you don't like it, don't use it" is a bogus argument, and should be
> shot on sight.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/1d207dd9/attachment.html>

From andrew.gibiansky at gmail.com  Tue Sep  8 02:17:54 2015
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Mon, 7 Sep 2015 19:17:54 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJumaK-ZCPv65qvYxkW0=y2RG0iFhNJGQavNJ-_afeCpcJS_Tw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <CAD=7U2AXYd9YSXCpQrmxdztBptaUZryRGfPFR3puyGM+7NYfSg@mail.gmail.com>
 <CAJumaK-ZCPv65qvYxkW0=y2RG0iFhNJGQavNJ-_afeCpcJS_Tw@mail.gmail.com>
Message-ID: <CAF-LYK+nrnN81qqJSMa7yL-siPcjs5wN82ZfULStSjV0yKPXxw@mail.gmail.com>

Very little changes. You can look at the changes to Parser.y on the Phabricator
revision <https://phabricator.haskell.org/D1219#72873ca7>. In order to get
this parsing sans any shift/reduce conflicts you have to introduce fexp2 as
well as fexp, which makes it so that dollar-less lambdas/do blocks can only
be applied as the last argument.

-- Andrew

On Mon, Sep 7, 2015 at 6:39 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Reserving judgment on the merits of the proposal, I would be curious to
> see the net impact of such a change on the grammar that GHC parses. How
> much changes?
>
> -Edward
>
> On Mon, Sep 7, 2015 at 9:15 PM, Mike Meyer <mwm at mired.org> wrote:
>
>> On Mon, Sep 7, 2015 at 8:08 PM Dan Burton <danburton.email at gmail.com>
>> wrote:
>>
>>> +1 people who like it can use it and people who don't like it don't have
>>> to use it.
>>>
>>
>> Yes, but they still have to be able to read code that uses it, deal with
>> it in coding standards, deal with how it affects their tool chain, and
>> otherwise have it affect them.
>>
>> "If you don't like it, don't use it" is a bogus argument, and should be
>> shot on sight.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/2380668f/attachment.html>

From rnmss.hs at gmail.com  Tue Sep  8 03:35:08 2015
From: rnmss.hs at gmail.com (RnMss ForHaskellMailList)
Date: Tue, 8 Sep 2015 11:35:08 +0800
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <0387e819-056e-467b-87a2-c9db3963ae18@googlegroups.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <0387e819-056e-467b-87a2-c9db3963ae18@googlegroups.com>
Message-ID: <CANNywisW1TiJo+uoj6SjOtOqeboHNVC8ST45W2RU103uJQqz4w@mail.gmail.com>

No, I didn't know there such wiki page. Thank you.

2015-09-08 4:05 GMT+08:00 Alexey Muranov <alexey.muranov at gmail.com>:

> You saw this, right?
>
> https://wiki.haskell.org/Nitpicks#Base-related_nitpicks
>
> (Just in case, maybe it was you who included this topic.)
>
> Alexey.
>
>
> On Monday, September 7, 2015 at 4:08:54 PM UTC+2, DreamApart AtHaskells
> wrote:
>>
>> The class Num defines the method functions like (+), (-), (*), negate,
>> ...
>> But they are actually different concepts.
>>
>> We often meet situations that we want an addition for some type, but
>> not a multiplication. For example:
>>
>>     *data* Vec3 = Vec3 Float Float Float
>>
>> The additive (and subtractive) operation is obvious, but not for a
>> multiplication.
>>
>> *  Note*
>>
>>     (*) :: a -> a -> a   -- not avaliable for a Vec3
>>
>>     scale :: Float -> Vec3 -> Vec3
>>     dot :: Vec3 -> Vec3 -> Float
>>
>> We cannot define a (+) alone for a type, so we got many different
>> functions
>> from different libs, like mappend, mplus, plus, (<+>), (.+.), (+.),
>> which all reads
>> "plus".
>>
>> My opinion is that the methods of Num should be seperated into different
>> type
>> classes, so we don't need to invent a new symbol for a new lib.
>>
>> A feasible design is:
>>
>>     *import* Prelude *hiding* ( Num (..), Monoid (..), sum )
>>
>>     *class* SemiGroup a *where*
>>         (+)         :: a -> a -> a
>>
>>     *class* SemiGroup a => Monoid a *where*
>>         zero        :: a
>>
>>     *class* Monoid a => Group a *where*
>>         negate      :: a -> a
>>         (-)         :: a -> a -> a
>>
>>         x - y    = x + negate y
>>         negate x = zero - x
>>
>>     *class* Group a => Ring a *where   *-- not sure about the name ...
>>         (*)         :: a -> a -> a
>>
>>     *class* Ring a => Num a *where*
>>         abs         :: a -> a
>>         signum      :: a -> a
>>         fromInteger :: Integer -> a
>>
>>     sum :: (Foldable t, Monoid a) => t a -> a
>>     sum = foldl' (+) zero
>>
>>     -- for compatibility
>>     mempty = zero
>>     mappend = (+)
>>     mconcat = sum
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/37f163ec/attachment.html>

From ok at cs.otago.ac.nz  Tue Sep  8 03:47:47 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Tue, 8 Sep 2015 15:47:47 +1200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
Message-ID: <6AB294CF-265A-41FB-B014-47AD10D4A790@cs.otago.ac.nz>


On 8/09/2015, at 2:08 am, DreamApart AtHaskells <rnmss.hs at gmail.com> wrote:
>     class SemiGroup a where
>         (+)         :: a -> a -> a
> 
>     class Group a => Ring a where   -- not sure about the name ...
>         (*)         :: a -> a -> a
>     
>     class Ring a => Num a where
>         abs         :: a -> a
>         signum      :: a -> a
>         fromInteger :: Integer -> a
> 
>     sum :: (Foldable t, Monoid a) => t a -> a
>     sum = foldl' (+) zero

Traditionally, + is used only for Abelian groups,
with a non-commutative binary operation being thought
of as a "product", not a sum.  I am not very happy
at the idea of being told to use the wrong operator
for a group operation.

Sounds like you want NumericPrelude.
(Or possibly the AXIOM computer algebra language...)


From spam at scientician.net  Tue Sep  8 04:02:54 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 8 Sep 2015 06:02:54 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
Message-ID: <mslmld$f6t$1@ger.gmane.org>

On 09/08/2015 03:08 AM, Dan Burton wrote:
> +1 people who like it can use it and people who don't like it don't have to
> use it. Personally I wish it were the default because the superfluous $
> confuses a lot of people coming from other languages like Ruby.
> 

Whether it's "superfluous" depends entirely on one's PoV.

> You can even write in the old style if you have the extension turned on. It
> doesn't disable the old way of doing things. It just allows a new way. It's
> entirely backwards compatible with working code when turned on, is it not?
> 

Except now there are two "dialects" everybody has to read/understand.
That's not progress IMO. (Considering that it's so little gain. I really
don't understand the hatred of $ that some people seem to have.)

Regards,



From andrew.gibiansky at gmail.com  Tue Sep  8 04:56:43 2015
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Mon, 7 Sep 2015 21:56:43 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <mslmld$f6t$1@ger.gmane.org>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
Message-ID: <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>

In order to get a feel for  using this extension in real-world Haskell,
take a look at the new ghc-reskin package:

https://github.com/gibiansky/ghc-reskin

This allows you to use ArgumentBlock *today* by passing GHC a few
parameters to tell it to use ghc-reskin as a preprocessor. Take a look at
the README for a full example.

-- Andrew

On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> On 09/08/2015 03:08 AM, Dan Burton wrote:
> > +1 people who like it can use it and people who don't like it don't have
> to
> > use it. Personally I wish it were the default because the superfluous $
> > confuses a lot of people coming from other languages like Ruby.
> >
>
> Whether it's "superfluous" depends entirely on one's PoV.
>
> > You can even write in the old style if you have the extension turned on.
> It
> > doesn't disable the old way of doing things. It just allows a new way.
> It's
> > entirely backwards compatible with working code when turned on, is it
> not?
> >
>
> Except now there are two "dialects" everybody has to read/understand.
> That's not progress IMO. (Considering that it's so little gain. I really
> don't understand the hatred of $ that some people seem to have.)
>
> Regards,
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150907/1f3a25bf/attachment.html>

From targen at gmail.com  Tue Sep  8 04:57:52 2015
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Tue, 8 Sep 2015 00:27:52 -0430
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <mslmld$f6t$1@ger.gmane.org>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
Message-ID: <CAJWnFaNqWrR8DARau044YGv9FRpCQ-yE59hfcjJe8UnzVOcnfQ@mail.gmail.com>

On 09/08/2015 03:08 AM, Dan Burton wrote:
> You can even write in the old style if you have the extension turned on. It
> doesn't disable the old way of doing things. It just allows a new way. It's
> entirely backwards compatible with working code when turned on, is it not?

On Mon, Sep 7, 2015 at 11:32 PM, Bardur Arantsson <spam at scientician.net> wrote:
> Except now there are two "dialects" everybody has to read/understand.
> That's not progress IMO. (Considering that it's so little gain. I really
> don't understand the hatred of $ that some people seem to have.)

Every library published on Hackage could be said to create a new
dialect of Haskell for some specific purpose.  Operator-heavy,
multipurpose libraries such as lens could also be said to introduce
new dialects.  Yes, they all parse under the same grammar, but if you
don?t know the fixity of some operator, it might as well be some
strange unknown syntax ? let alone not knowing what it actually does.

We?re so used to understanding complex semantics and diverse,
sometimes even obtuse styles of expression (pointfree, anyone?).
Surely the mental effort of parsing a lambda or a do-block in a new,
previously invalid syntax is a trivial matter for programmers
accustomed to running type checking algorithms in our heads.

From spam at scientician.net  Tue Sep  8 05:29:33 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 8 Sep 2015 07:29:33 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJWnFaNqWrR8DARau044YGv9FRpCQ-yE59hfcjJe8UnzVOcnfQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAJWnFaNqWrR8DARau044YGv9FRpCQ-yE59hfcjJe8UnzVOcnfQ@mail.gmail.com>
Message-ID: <mslrns$p62$1@ger.gmane.org>

On 09/08/2015 06:57 AM, Manuel G?mez wrote:
> On 09/08/2015 03:08 AM, Dan Burton wrote:
>> You can even write in the old style if you have the extension turned on. It
>> doesn't disable the old way of doing things. It just allows a new way. It's
>> entirely backwards compatible with working code when turned on, is it not?
> 
> On Mon, Sep 7, 2015 at 11:32 PM, Bardur Arantsson <spam at scientician.net> wrote:
>> Except now there are two "dialects" everybody has to read/understand.
>> That's not progress IMO. (Considering that it's so little gain. I really
>> don't understand the hatred of $ that some people seem to have.)
> 
> Every library published on Hackage could be said to create a new
> dialect of Haskell for some specific purpose.  Operator-heavy,
> multipurpose libraries such as lens could also be said to introduce
> new dialects.  Yes, they all parse under the same grammar, but if you
> don?t know the fixity of some operator, it might as well be some
> strange unknown syntax ? let alone not knowing what it actually does.
> 
> We?re so used to understanding complex semantics and diverse,
> sometimes even obtuse styles of expression (pointfree, anyone?).
> Surely the mental effort of parsing a lambda or a do-block in a new,
> previously invalid syntax is a trivial matter for programmers
> accustomed to running type checking algorithms in our heads.

If this were LISP or Scheme (i.e. macros), I'd agree with you :).
Needless to say, I don't when it comes to Haskell.

(Again because this adds *so* little convenience.)

Regards,


From alexey.muranov at gmail.com  Tue Sep  8 07:01:58 2015
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Tue, 8 Sep 2015 00:01:58 -0700 (PDT)
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
Message-ID: <d8bb5711-3221-4cf1-99e1-817eced1fe1c@googlegroups.com>

My, maybe naive, impression is that there should always be one class per 
operation, as this is obviously the most flexible approach. Then maybe some 
classes can be grouped together by introducing other classes.

Alexey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/6ffaf2ae/attachment.html>

From ekmett at gmail.com  Tue Sep  8 07:04:30 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 8 Sep 2015 03:04:30 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
Message-ID: <CAJumaK8Va_ak+T2VT9=tGCbf5-XppabX1sSm_ihGL82iB2JiMA@mail.gmail.com>

I do have to admit that the syntax there feels lighter and less cluttered.
I could get used to it.

-Edward

On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <
andrew.gibiansky at gmail.com> wrote:

> In order to get a feel for  using this extension in real-world Haskell,
> take a look at the new ghc-reskin package:
>
> https://github.com/gibiansky/ghc-reskin
>
> This allows you to use ArgumentBlock *today* by passing GHC a few
> parameters to tell it to use ghc-reskin as a preprocessor. Take a look at
> the README for a full example.
>
> -- Andrew
>
> On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net>
> wrote:
>
>> On 09/08/2015 03:08 AM, Dan Burton wrote:
>> > +1 people who like it can use it and people who don't like it don't
>> have to
>> > use it. Personally I wish it were the default because the superfluous $
>> > confuses a lot of people coming from other languages like Ruby.
>> >
>>
>> Whether it's "superfluous" depends entirely on one's PoV.
>>
>> > You can even write in the old style if you have the extension turned
>> on. It
>> > doesn't disable the old way of doing things. It just allows a new way.
>> It's
>> > entirely backwards compatible with working code when turned on, is it
>> not?
>> >
>>
>> Except now there are two "dialects" everybody has to read/understand.
>> That's not progress IMO. (Considering that it's so little gain. I really
>> don't understand the hatred of $ that some people seem to have.)
>>
>> Regards,
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/8d4ec8ce/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Tue Sep  8 07:43:03 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 8 Sep 2015 09:43:03 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <6AB294CF-265A-41FB-B014-47AD10D4A790@cs.otago.ac.nz>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <6AB294CF-265A-41FB-B014-47AD10D4A790@cs.otago.ac.nz>
Message-ID: <55EE9187.8040508@unicaen.fr>

Richard A. O'Keefe comments :
> Sounds like you want NumericPrelude.
> (Or possibly the AXIOM computer algebra language...)

Just a word.
This is a quite old subject, "reinvented" many times. A neverending story...

Already twenty (yes!) years ago, in:

/Functional programming languages in education : first international 
symposium, FPLE '95, Nijmegen, the Netherlands, December 4-6, 1995/

you may find two talks about it, one by  Jeroen Fokker, and other, mine.

Then, Sergei Mechveliani worked some years on it, and constructed DoCon, 
the Algebraic Domain Constructor (accessible here:
http://homepages.inf.ed.ac.uk/wadler/realworld/docon2.html )

Presumably there are other implementations as well. I know, but I lost 
the references, that some people worked on such constructs in Clean, 
where the type class structure is a bit different than in Haskell, some 
generalizations are easier to implement.

Jerzy Karczmarczuk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/1cc6821e/attachment.html>

From k-bx at k-bx.com  Tue Sep  8 07:45:12 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Tue, 8 Sep 2015 10:45:12 +0300
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
Message-ID: <CAAbahfRk1WuT1X0W-Tck9BAPTzqZBWDK3=rK+VWLGTmtf9OrYw@mail.gmail.com>

Thanks, after re-considering this, I think moving towards -Werror (and
making this a "good style") works good enough and is the best solution for
this problem right now. Hopefully I'll find time to remove all warnings at
once to make its usage possible.

On Thu, Sep 3, 2015 at 2:23 AM, Thomas Koster <tkoster at gmail.com> wrote:

> On 3 September 2015 at 04:44, Kostiantyn Rybnikov <k-bx at k-bx.com> wrote:
> > There's a common situation I get into: I compile with "stack build" (or
> > cabal build), get a big list of warnings, fix few of them, then I
> re-compile
> > project, but a lot of warnings are gone now. The only option I'm left
> with
> > is to use "-fforce-recomp".
>
> If you're going to fix all the warnings anyway, why not just use -Werror?
>
> --
> Thomas Koster
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/f712d270/attachment.html>

From edv.karol at gmail.com  Tue Sep  8 07:49:50 2015
From: edv.karol at gmail.com (Karol Samborski)
Date: Tue, 8 Sep 2015 09:49:50 +0200
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAAbahfRk1WuT1X0W-Tck9BAPTzqZBWDK3=rK+VWLGTmtf9OrYw@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
 <CAAbahfRk1WuT1X0W-Tck9BAPTzqZBWDK3=rK+VWLGTmtf9OrYw@mail.gmail.com>
Message-ID: <CACe2dTvAHmS+O2tu-D1VUQ8_eE7t=1QK8P_HOhz+Y9LjeP_paQ@mail.gmail.com>

2015-09-08 9:45 GMT+02:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> Thanks, after re-considering this, I think moving towards -Werror (and
> making this a "good style") works good enough and is the best solution for
> this problem right now. Hopefully I'll find time to remove all warnings at
> once to make its usage possible.
>

You can always use cabal build --ghc-options="-Wall -fno-code" then
fix warnings and errors and then compile.

Karol

From simonpj at microsoft.com  Tue Sep  8 08:29:39 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Sep 2015 08:29:39 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJumaK8Va_ak+T2VT9=tGCbf5-XppabX1sSm_ihGL82iB2JiMA@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAJumaK8Va_ak+T2VT9=tGCbf5-XppabX1sSm_ihGL82iB2JiMA@mail.gmail.com>
Message-ID: <34a021539d7d45de9e52295264fa2a83@DB4PR30MB030.064d.mgd.msft.net>

FWIW, I?m neutral.

Simon

From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 08 September 2015 08:05
To: Andrew Gibiansky
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock

I do have to admit that the syntax there feels lighter and less cluttered. I could get used to it.

-Edward

On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <andrew.gibiansky at gmail.com<mailto:andrew.gibiansky at gmail.com>> wrote:
In order to get a feel for  using this extension in real-world Haskell, take a look at the new ghc-reskin package:

https://github.com/gibiansky/ghc-reskin

This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example.

-- Andrew

On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net<mailto:spam at scientician.net>> wrote:
On 09/08/2015 03:08 AM, Dan Burton wrote:
> +1 people who like it can use it and people who don't like it don't have to
> use it. Personally I wish it were the default because the superfluous $
> confuses a lot of people coming from other languages like Ruby.
>

Whether it's "superfluous" depends entirely on one's PoV.

> You can even write in the old style if you have the extension turned on. It
> doesn't disable the old way of doing things. It just allows a new way. It's
> entirely backwards compatible with working code when turned on, is it not?
>

Except now there are two "dialects" everybody has to read/understand.
That's not progress IMO. (Considering that it's so little gain. I really
don't understand the hatred of $ that some people seem to have.)

Regards,


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/f3159c8b/attachment.html>

From miguelimo38 at yandex.ru  Tue Sep  8 08:39:57 2015
From: miguelimo38 at yandex.ru (Miguel Mitrofanov)
Date: Tue, 08 Sep 2015 11:39:57 +0300
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJumaK8Va_ak+T2VT9=tGCbf5-XppabX1sSm_ihGL82iB2JiMA@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAJumaK8Va_ak+T2VT9=tGCbf5-XppabX1sSm_ihGL82iB2JiMA@mail.gmail.com>
Message-ID: <585901441701597@web30o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/dbb81a67/attachment.html>

From alexander at plaimi.net  Tue Sep  8 09:41:28 2015
From: alexander at plaimi.net (Alexander Berntsen)
Date: Tue, 8 Sep 2015 11:41:28 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <55EEAD48.4070908@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -1 for several reasons already articulated by others.

- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJV7q1HAAoJENQqWdRUGk8BhwAP/0JwoJ6ueXSfu7ux3GpzYGIj
PBfS4+FwJ2eePmHW/YZMaOYBiHfyhSWYWLFu5vLB9lV4Qkd0m/XpywakHTQwJgqt
VQWwFJYDv5qf2UZ1FcL0un8jOXJcNu8A8PwuXhClJz+GuAZstn18321MWRJHY+XH
cxD+FFjJrLHEy5q0Erh3fwTFKzm3vSA/MQbFnwz0KKmpi3/psoKy5whKSSmmm2k1
uzUH9Xpn/RTi607W7hW9/YzD8EaFmHi0/hN6vY7z2OJheQ2xpUbRef3gRytpkDLe
/WB/Ud/ksFzss5aJWCljlbjq1gpGGyTxcb6lFIyP2N7SCTNs0h/4a5+1wxaVXyrD
3TVfds3DrEC/JFKiVkVzulwnVTrQKI7MnS2IFhOVKvCmlRGnf3MSBopCIyB5mIcS
AkzCYDdQW1CbdJ/8wYhwi/Hl53lImVGiDx3a1t5X/lgJOo1hgwVhAXCsxGk5ylho
wGLXAt8YFowVtqAu3aQAvsy/EkYWh2WZ1mmQr+Fhu6+fsJWP34DU440nLUZhdcHL
n4OHFH7nBK2T/JehD9nLOAe3sBJ5sXsVjBCjvMlNA9/kEwFxreutBlGmsnOpsz+b
fgsdiQtwcgPeUu0nsOii/1abhAgMr9ybeYyteoO4x/ltKpjx+QlNVwm2ZFxgYvQI
jdIuoZbe2oj12D/+VByR
=l4Yp
-----END PGP SIGNATURE-----

From fumiexcel at gmail.com  Tue Sep  8 09:48:43 2015
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Tue, 8 Sep 2015 18:48:43 +0900
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <CAATCwUnUKvVhuUiqy56W+XJ83oQjx_Hj0A+frK-664M3RR2X9Q@mail.gmail.com>

It would be quite useful. It allows us to write

    foo $!%$*~ runBarT do ...

Instead of

    (foo $!%$*~) $ runBarT $ do ...

2015-09-06 7:55 GMT+09:00 Andrew Gibiansky <andrew.gibiansky at gmail.com>:

> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> the following code:
>
> main = when True do
>   putStrLn "Hello!"
>
>
> main = forM values \value ->
>   print value
>
>
> main = forM values \case
>     Just x -> print x
>     Nothing -> print y
>
>
> In this code we do not need `$` before `do`, lambda, or lambda-case (if
> -XLambdaCase is enabled). This change would *not* extend to `let`, `if`,
> `case`, or any other constructs.
>
> Pros:
>
> 1. Code is simpler and it greatly reduces the need for "operator line
> noise" of $ everywhere.
> 2. We can avoid using the type-checker hack for $
> <http://stackoverflow.com/questions/9468963/runst-and-function-composition>
> for things such as runSt.
>
> Cons:
>
> 1. Adds complexity to the compiler. (NB: The change is minimal and not
> invasive at all.)
> 2. Contributes to a proliferation of extensions that other tools must
> support.  (NB: This is just a parser change so should be easy for all tools
> to support.)
>
> I'm very interested in hearing both favoring and dissenting opinions on
> this proposed change. If this change is approved of, names besides
> -XArgumentBody can be considered.
>
> See more info on Trac
> <https://ghc.haskell.org/trac/ghc/ticket/10843#ticket>.
>
> -- Andrew Gibiansky
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/aca40580/attachment.html>

From abela at chalmers.se  Tue Sep  8 11:54:04 2015
From: abela at chalmers.se (Andreas Abel)
Date: Tue, 8 Sep 2015 13:54:04 +0200
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CACe2dTvAHmS+O2tu-D1VUQ8_eE7t=1QK8P_HOhz+Y9LjeP_paQ@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
 <CAAbahfRk1WuT1X0W-Tck9BAPTzqZBWDK3=rK+VWLGTmtf9OrYw@mail.gmail.com>
 <CACe2dTvAHmS+O2tu-D1VUQ8_eE7t=1QK8P_HOhz+Y9LjeP_paQ@mail.gmail.com>
Message-ID: <55EECC5C.6070907@chalmers.se>

On 08.09.2015 09:49, Karol Samborski wrote:
> You can always use cabal build --ghc-options="-Wall -fno-code" then
> fix warnings and errors and then compile.

Would be nice if that worked, but with TemplateHaskell -fno-code does 
not get you very far...

Andreas

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From andreas.abel at ifi.lmu.de  Tue Sep  8 12:06:41 2015
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 8 Sep 2015 14:06:41 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
Message-ID: <55EECF51.4070400@ifi.lmu.de>

+1 to Andrew's original proposal.  It is as old as lambda-calculus 
itself, and I do not know why anything else was ever implemented for 
Haskell.

Agda got the parsing of \lambda right, and recently also the \forall.

 
https://github.com/agda/agda/commit/7d84d57aad07b4fd452a4a62c91a5b83fe7e6020

--Andreas

On 06.09.2015 00:55, Andrew Gibiansky wrote:
> I'd like to propose a GHC extension called (for now) `ArgumentBody`.
> `ArgumentBody` is a simple syntax extension, than, when enabled, permits
> the following code:
>
> main  =  whenTrue  do
>    putStrLn"Hello!"
>
>
> main  =  forM values\value->
>    print value
>
>
> main  =  forM values\case
>      Just  x->  print x
>      Nothing  ->  print y
>
>
> In this code we do not need `$` before `do`, lambda, or lambda-case (if
> -XLambdaCase is enabled). This change would /not/ extend to `let`, `if`,
> `case`, or any other constructs.
>
> Pros:
>
> 1. Code is simpler and it greatly reduces the need for "operator line
> noise" of $ everywhere.
> 2. We can avoid using the type-checker hack for $
> <http://stackoverflow.com/questions/9468963/runst-and-function-composition>
> for things such as runSt.
>
> Cons:
>
> 1. Adds complexity to the compiler. (NB: The change is minimal and not
> invasive at all.)
> 2. Contributes to a proliferation of extensions that other tools must
> support.  (NB: This is just a parser change so should be easy for all
> tools to support.)
>
> I'm very interested in hearing both favoring and dissenting opinions on
> this proposed change. If this change is approved of, names besides
> -XArgumentBody can be considered.
>
> See more info on Trac
> <https://ghc.haskell.org/trac/ghc/ticket/10843#ticket>.
>
> -- Andrew Gibiansky
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From andreas.abel at ifi.lmu.de  Tue Sep  8 12:27:44 2015
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 8 Sep 2015 14:27:44 +0200
Subject: [Haskell-cafe] "Assignment" in do blocks?
In-Reply-To: <55EDF12A.300@gmail.com>
References: <CAKit5aD_je06tyG6wQC+zu+EsVa0fmKQPU2YwuRgoGuK8Wk9jQ@mail.gmail.com>
 <CAPY+ZdRf3Toy6dNYhDXF7bTn_pSc7a0pPen2xpX8cWqCqSiRcQ@mail.gmail.com>
 <CAKit5aAtpV6HLzU-QvjbNk5p+Hib8v_squzHJtB-vN322B+wgw@mail.gmail.com>
 <55EDF12A.300@gmail.com>
Message-ID: <55EED440.2020902@ifi.lmu.de>

On 07.09.2015 22:18, Silvio Frischknecht wrote:
> Looking at the nitpick list, I just remembered that there was a
> discussion about making let optional in do bindings a couple of years ago.
>
> https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102741.html
>
> One of the major stumbling points was how recursive bindings should
> work. These these two proposals would combine nicely.
>
> adding a statement
>
> pat = exp
>
> that expresses a non-recursive let.

Exactly!  +1 from me.

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From vagarenko at gmail.com  Tue Sep  8 12:36:12 2015
From: vagarenko at gmail.com (Alexey Vagarenko)
Date: Tue, 8 Sep 2015 18:36:12 +0600
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
Message-ID: <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>

Consider this.
If we didn't have $ operator in the first place, we'd use parentheses
everywhere:

    foo (bar (baz (qux (quux (do a <- b; return a)))))
under your proposal it turns to:
    foo (bar (baz (qux (quux do a <- b; return a))))

another example:
    foo (bar baz) (qux quux) (do a <- b; return a)
turns to :
    foo (bar baz) (qux quux) do a <- b; return a

with lambdas:
    foo (bar baz) (qux quux) (\x -> x)
to:
    foo (bar baz) (qux quux) \x -> x

Can't you see your proposal makes things *less *consistent, *not more*?
-1.

2015-09-07 0:03 GMT+06:00 Oliver Charles <ollie at ocharles.org.uk>:

> I mean that people us $ for purely syntactical purposes. If an editor is
> going to make refactorings and retain a certain sense of style, then the
> tool needs to know that $ is sometimes to be used. The refactoring (or
> otherwise) tool now has to be aware of the syntax of Haskell and special
> symbols in the Prelude.
>
> On Sun, Sep 6, 2015 at 6:53 PM Matthew Pickering <
> matthewtpickering at gmail.com> wrote:
>
>> >
>> > I don't really like $ from an editor perspective though (tooling has to
>> > become aware of a single function when performing refactorings), so
>> anything
>> > that helps reduce how prolific that operator is is a win in my book!
>> >
>>
>> Can you please explain what you mean by this? Is there something more
>> subtle that $ being a low fixity operator? Which specific problems
>> does it cause tooling? Are you referring to the fact that there are
>> problems because $ == id and makes tooling account for two cases when
>> looking for refactorings? (I'm thinking of hlint here).
>>
>> (FWIW, haskell-src-exts tries to fiddle with the AST to account for
>> fixity after parsing but the GHC parser does not, it happens during
>> renaming. There is a pure version here[1] if anyone else is in need of
>> this feature).
>>
>> Thanks, Matt
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/35e99893/attachment.html>

From gregmainland at gmail.com  Tue Sep  8 12:41:46 2015
From: gregmainland at gmail.com (Greg Horn)
Date: Tue, 08 Sep 2015 12:41:46 +0000
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
Message-ID: <CAAr-h4v6kKXKAQG1YFM2TYEkO-wdPs3oPVa2csSoQNr-ZxW3Wg@mail.gmail.com>

>
> If you're going to fix all the warnings anyway, why not just use -Werror?


I'm not sure if this is ghci or emacs haskell-mode, but if I use -Werror in
my cabal file then any warnings will cause ghci to fail loading, and I
can't use helpful interactive features like `:t myFunction` or `print
someValue`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/ac5c5454/attachment.html>

From andreas.abel at ifi.lmu.de  Tue Sep  8 12:42:01 2015
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 8 Sep 2015 14:42:01 +0200
Subject: [Haskell-cafe] I wrote a type checker: ARF. Is it novel?
In-Reply-To: <55ED02AC.7010109@gmail.com>
References: <55ED02AC.7010109@gmail.com>
Message-ID: <55EED799.4040801@ifi.lmu.de>

Why not use one of the 40-year old type checking algorithms?

   https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system

What type do you infer for

   def id(n):
       return n

?

On 07.09.2015 05:21, David Foster wrote:
> I've written a small untyped language calculus (ARF) and an
> interprocedural flow-based type checker to explore techniques for
> efficiently inferring all types in the presence of recursive function
> calls, with no prior type declarations or annotations required in the
> original program.
>
> The type checking algorithm I've come up with appears not only to work
> but also to have good performance: O(m^2) time in the worst case and
> O(m) time in the average case, where m is the number of functions in the
> program.
>
> So the question I'd like to pose to any type system buffs on this list is:
> (1) Is such an interprocedural flow-based type checking algorithm with
> that kind of performance likely to be novel?
>
> And if you have some interest and time to actually review the strategy
> and/or implementation of the algorithm at
> <https://github.com/davidfstr/arf#assign-recurse-flow-arf>, I'd love to
> know:
> (2) Are there similar type checking algorithms that already exist in the
> academic literature?
>
> I'm posting these questions here because I'm guessing that a number of
> folk that work with type systems and type checkers are likely to be
> subscribed to this list. If there are other more-appropriate venues, I'd
> love to hear about about them as well.
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From alexander at plaimi.net  Tue Sep  8 13:35:00 2015
From: alexander at plaimi.net (Alexander Berntsen)
Date: Tue, 8 Sep 2015 15:35:00 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
Message-ID: <55EEE404.2080104@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

($) is just a function like any other*, so I don't think it's a great
argument for or against a syntax extension.

*Bar a few details like the special infix typing rule for
accommodating impredicative polymorphism.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJV7uQDAAoJENQqWdRUGk8BA3wQAMdZ3xHQDYUy17HahMbMjxyT
xkm2bZLDNMPwmyaciGHsC+BeRae9Oo1oVgjWDDzrL41zSf9e2GS5SmEQumJeAgLm
TNkJgctJ44Ej+yPnJkik9OCK4YsFjZPFYdj8iI4T7uEBfC5vDQczODgKvcXo3WiY
JmujgC+QFjU3PaDaz8HZ8UzDIRszBRPQyTTLzlYnsshQwws/eU7W1hBKBLNFjn90
t9n8xq49BfbNInHSzVy5CbUW5VyPCYikkCAz7zRBc25iWtaXODvYnDCyc4vwVg38
QsNfXvOsSrnE80WOQxXKbaHutMaf8QoiNQ5+M8gMNKWAHXZ0ROYgAE9lm2QfLMTE
oidjVh9WrYmlXCmJl0pgFdN1Dc5J+KimoTK8ttvGcweRckUdgkBRQsmyqILtn+ql
peNN9QU5W1V8rUfliTq9XCXDu1rAKuKtSPb3GQD9vXDQ22QSHQqjk8eLdd2bAK1n
ji/r+Bjp9XNLvySaPi9neiEp3geFjZnN7b3pC2QtDsRJozv6prliNHOsGgLin5dN
FmrwSXysha7hZtxy3ze4XnMa/91GZPB9Z91hZdALXyVSbDBrE4ukUABprI6tK8/6
O2pfmsdWzvGMNgXFibg1sgJk9e8aTvp6YPyi6Xyj/88hLD6YxB3/ekxxBy00EDW/
RFqKfswkYKypfKwx0FXq
=8Rg1
-----END PGP SIGNATURE-----

From mantkiew at gsd.uwaterloo.ca  Tue Sep  8 14:10:35 2015
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Tue, 8 Sep 2015 10:10:35 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
Message-ID: <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>

+1 for the change but not for an extension. Here's why

1. I remember when I was new to Haskell, having to add $ confused me a lot.
It caused a lot of frustration, some errors I didn't understand, which
didn't help me realize that $ was needed. I still vividly remember the
pain....

2. It seems the change is fully backwards compatible and it does not
prevent people still using the old style if they wanted. I would make it a
default, not an extension.

3. In order to verify backwards compatibility, I would generate Core output
for all of Hackage with both the current and the new compilers and check
that Core remains identical. That would be a conclusive proof to me.

4. Regarding the other mentioned extensions like multiway if, etc. they
should become default as well because they are backwards compatible as
well.

5. The only reason to guard changes behind LANGUAGE pragmas should be when
they are causing problems with other extensions.

I too feel that Haskell community is becoming more and more conservative. I
believe there's still time now to make the language as best it can be at
the cost of loosing backwards compatibility. The rapid improvements in the
language is what attracts me to Haskell.

Best,
Micha?

On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <
andrew.gibiansky at gmail.com> wrote:

> In order to get a feel for  using this extension in real-world Haskell,
> take a look at the new ghc-reskin package:
>
> https://github.com/gibiansky/ghc-reskin
>
> This allows you to use ArgumentBlock *today* by passing GHC a few
> parameters to tell it to use ghc-reskin as a preprocessor. Take a look at
> the README for a full example.
>
> -- Andrew
>
> On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net>
> wrote:
>
>> On 09/08/2015 03:08 AM, Dan Burton wrote:
>> > +1 people who like it can use it and people who don't like it don't
>> have to
>> > use it. Personally I wish it were the default because the superfluous $
>> > confuses a lot of people coming from other languages like Ruby.
>> >
>>
>> Whether it's "superfluous" depends entirely on one's PoV.
>>
>> > You can even write in the old style if you have the extension turned
>> on. It
>> > doesn't disable the old way of doing things. It just allows a new way.
>> It's
>> > entirely backwards compatible with working code when turned on, is it
>> not?
>> >
>>
>> Except now there are two "dialects" everybody has to read/understand.
>> That's not progress IMO. (Considering that it's so little gain. I really
>> don't understand the hatred of $ that some people seem to have.)
>>
>> Regards,
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/8b42d555/attachment.html>

From meditans at gmail.com  Tue Sep  8 14:12:10 2015
From: meditans at gmail.com (Carlo Nucera)
Date: Tue, 8 Sep 2015 16:12:10 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55EEE404.2080104@plaimi.net>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
 <55EEE404.2080104@plaimi.net>
Message-ID: <CALaN21NgaQTBRvXGnL9fvHbCd1rrPgaZfEgVtbLx+Z0cepXS1g@mail.gmail.com>

-1

I wouldn't like to read code written with this extension. It feels to
me like an ad-hoc case,
hindering the general uniformity of the language. It has been a nice
opportunity to read up
the haskell report, though :)

2015-09-08 15:35 GMT+02:00 Alexander Berntsen <alexander at plaimi.net>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> ($) is just a function like any other*, so I don't think it's a great
> argument for or against a syntax extension.
>
> *Bar a few details like the special infix typing rule for
> accommodating impredicative polymorphism.
> - --
> Alexander
> alexander at plaimi.net
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJV7uQDAAoJENQqWdRUGk8BA3wQAMdZ3xHQDYUy17HahMbMjxyT
> xkm2bZLDNMPwmyaciGHsC+BeRae9Oo1oVgjWDDzrL41zSf9e2GS5SmEQumJeAgLm
> TNkJgctJ44Ej+yPnJkik9OCK4YsFjZPFYdj8iI4T7uEBfC5vDQczODgKvcXo3WiY
> JmujgC+QFjU3PaDaz8HZ8UzDIRszBRPQyTTLzlYnsshQwws/eU7W1hBKBLNFjn90
> t9n8xq49BfbNInHSzVy5CbUW5VyPCYikkCAz7zRBc25iWtaXODvYnDCyc4vwVg38
> QsNfXvOsSrnE80WOQxXKbaHutMaf8QoiNQ5+M8gMNKWAHXZ0ROYgAE9lm2QfLMTE
> oidjVh9WrYmlXCmJl0pgFdN1Dc5J+KimoTK8ttvGcweRckUdgkBRQsmyqILtn+ql
> peNN9QU5W1V8rUfliTq9XCXDu1rAKuKtSPb3GQD9vXDQ22QSHQqjk8eLdd2bAK1n
> ji/r+Bjp9XNLvySaPi9neiEp3geFjZnN7b3pC2QtDsRJozv6prliNHOsGgLin5dN
> FmrwSXysha7hZtxy3ze4XnMa/91GZPB9Z91hZdALXyVSbDBrE4ukUABprI6tK8/6
> O2pfmsdWzvGMNgXFibg1sgJk9e8aTvp6YPyi6Xyj/88hLD6YxB3/ekxxBy00EDW/
> RFqKfswkYKypfKwx0FXq
> =8Rg1
> -----END PGP SIGNATURE-----
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From alexander at plaimi.net  Tue Sep  8 14:18:07 2015
From: alexander at plaimi.net (Alexander Berntsen)
Date: Tue, 8 Sep 2015 16:18:07 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
Message-ID: <55EEEE1F.6050909@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 08/09/15 16:10, Michal Antkiewicz wrote:
> 
> 2. It seems the change is fully backwards compatible and it does
> not prevent people still using the old style if they wanted. I
> would make it a default, not an extension.
> 
> 4. Regarding the other mentioned extensions like multiway if, etc.
>  they should become default as well because they are backwards 
> compatible as well.
> 
> 5. The only reason to guard changes behind LANGUAGE pragmas should
> be when they are causing problems with other extensions.
Anything that is not Haskell 2010 is *by definition* a language
extension. If you want to change the language, that is a discussion
for Haskell' not GHC.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJV7u4eAAoJENQqWdRUGk8BcQYP/R0H0B89ksE+eJEDMIoNB/QS
9zSP+m0r+RC6VkMP9N/WVHXRL8z7Egdrwvd6n9tVvlawGqPbKFJMdOy/n4b9KMn7
zI3hkwoSgFOwg9pMIiqcSh/NfGBBe5gPHS8jHkaBEqBFMPYRuIMor9+Wv0S7nDIW
f8BYjvl5spW7nmQHZobylGzcKD5uQENzKvEDClE+LpVv4hwBWI/SlXdTgSnUQbzV
1c/CAQPCUxzkgg8Fm0ToNWorefVP7jqdtoyCthEWckKH/qz1egbGoeYGvoUqOkq+
OjbhIWgSY7PJdIZTTNqlYXr948Uo1YAdcsb69a5jds17jGW+95FtNpKNu/coJydj
VRI/kKQYn/XiOo4Dks1Aw8gqQP6Y/HMs3jqlawbA+BXiZz2WbhjkJzLWYutiH76V
tFyScgTOK+wHGhpZQ6LcmDeK0rfjeQznRnK+AkulF5ZU51sJgc4whxN/JHG7eLq5
BUy1JF9oiFFqTy+7eLyEFXDv9Sy0EhQa/lDMrhRJ4OA4jrZYOK4Rvt12W2RQ4gsA
HS2gdPJuQdTqjCvjJIQKSTQaDUyiSSS4EHaVLAnu76aH1YOmBUo2uhIWDm2xJr2k
HUFxazyYJoif7R1G6gGM7wM8dOYNUphNuEHJd45sfMhZJF7kVGKcTz1Nnw+UaZ0f
KhLkBokcg+97xOPzLier
=uxsl
-----END PGP SIGNATURE-----

From danburton.email at gmail.com  Tue Sep  8 14:24:01 2015
From: danburton.email at gmail.com (Dan Burton)
Date: Tue, 8 Sep 2015 07:24:01 -0700
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55EEE404.2080104@plaimi.net>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
 <55EEE404.2080104@plaimi.net>
Message-ID: <CALSygwd+Qa4F9AR2uGEZS5g9=MG0GKHgYnQUoPNVD1ANRnFoyQ@mail.gmail.com>

    foo (bar (baz (qux (quux (do a <- b; return a)))))

Using function composition:

    (foo . bar . baz . qux . quux) (do a <- b; return a)
    (foo . bar . baz . qux . quux) do
      a <- b
      return a

Here's why I like the proposed extension, especially in a world without $.
It is because it enables intuitive multiline Haskell code with significant
white space rather than parens.

foo (bar baz) (qux quux) (do
  a <- b
  return a) -- ugh this close paren

foo (bar baz) (qux quux) do
  a <- b
  return a
  -- much nicer, "do" feels like the comparable Ruby keyword

The usage of $ to accomplish this is a hack that Haskellers have gotten
very accustomed to. It frequently trips up the uninitiated. It requires a
hack in the compiler when used with ST blocks.

On Tuesday, September 8, 2015, Alexey Vagarenko <vagarenko at gmail.com> wrote:

> Consider this.
> If we didn't have $ operator in the first place, we'd use parentheses
> everywhere:
>
>     foo (bar (baz (qux (quux (do a <- b; return a)))))
> under your proposal it turns to:
>     foo (bar (baz (qux (quux do a <- b; return a))))
>
> another example:
>     foo (bar baz) (qux quux) (do a <- b; return a)
> turns to :
>     foo (bar baz) (qux quux) do a <- b; return a
>
> with lambdas:
>     foo (bar baz) (qux quux) (\x -> x)
> to:
>     foo (bar baz) (qux quux) \x -> x
>
> Can't you see your proposal makes things *less *consistent, *not more*?
> -1.
>
> 2015-09-07 0:03 GMT+06:00 Oliver Charles <ollie at ocharles.org.uk
> <javascript:_e(%7B%7D,'cvml','ollie at ocharles.org.uk');>>:
>
>> I mean that people us $ for purely syntactical purposes. If an editor is
>> going to make refactorings and retain a certain sense of style, then the
>> tool needs to know that $ is sometimes to be used. The refactoring (or
>> otherwise) tool now has to be aware of the syntax of Haskell and special
>> symbols in the Prelude.
>>
>> On Sun, Sep 6, 2015 at 6:53 PM Matthew Pickering <
>> matthewtpickering at gmail.com
>> <javascript:_e(%7B%7D,'cvml','matthewtpickering at gmail.com');>> wrote:
>>
>>> >
>>> > I don't really like $ from an editor perspective though (tooling has to
>>> > become aware of a single function when performing refactorings), so
>>> anything
>>> > that helps reduce how prolific that operator is is a win in my book!
>>> >
>>>
>>> Can you please explain what you mean by this? Is there something more
>>> subtle that $ being a low fixity operator? Which specific problems
>>> does it cause tooling? Are you referring to the fact that there are
>>> problems because $ == id and makes tooling account for two cases when
>>> looking for refactorings? (I'm thinking of hlint here).
>>>
>>> (FWIW, haskell-src-exts tries to fiddle with the AST to account for
>>> fixity after parsing but the GHC parser does not, it happens during
>>> renaming. There is a pure version here[1] if anyone else is in need of
>>> this feature).
>>>
>>> Thanks, Matt
>>>
>>
>

-- 
-- Dan Burton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/f441ff10/attachment.html>

From J.Burton at brighton.ac.uk  Tue Sep  8 14:29:46 2015
From: J.Burton at brighton.ac.uk (James Burton)
Date: Tue, 8 Sep 2015 14:29:46 +0000
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
Message-ID: <85d99d88-2645-451e-9062-bb78fce5db22@email.android.com>


On 8 Sep 2015 3:12 pm, Carlo Nucera <meditans at gmail.com> wrote:
>
> -1
>
> I wouldn't like to read code written with this extension. It feels to
> me like an ad-hoc case,
> hindering the general uniformity of the language.

I agree, and think it could be confusing to switch between styles in different codebases or in a single codebase.

I teach Haskell and encourage students to use brackets liberally if they're not sure when they're needed and experiment with removing redundant ones and replacing others with $ later on. I don't think this is one of the things they tend to get confused about.

> It has been a nice
> opportunity to read up
> the haskell report, though :)
>
> 2015-09-08 15:35 GMT+02:00 Alexander Berntsen <alexander at plaimi.net>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > ($) is just a function like any other*, so I don't think it's a great
> > argument for or against a syntax extension.
> >
> > *Bar a few details like the special infix typing rule for
> > accommodating impredicative polymorphism.
> > - --
> > Alexander
> > alexander at plaimi.net
> > https://secure.plaimi.net/~alexander
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> >
> > iQIcBAEBCgAGBQJV7uQDAAoJENQqWdRUGk8BA3wQAMdZ3xHQDYUy17HahMbMjxyT
> > xkm2bZLDNMPwmyaciGHsC+BeRae9Oo1oVgjWDDzrL41zSf9e2GS5SmEQumJeAgLm
> > TNkJgctJ44Ej+yPnJkik9OCK4YsFjZPFYdj8iI4T7uEBfC5vDQczODgKvcXo3WiY
> > JmujgC+QFjU3PaDaz8HZ8UzDIRszBRPQyTTLzlYnsshQwws/eU7W1hBKBLNFjn90
> > t9n8xq49BfbNInHSzVy5CbUW5VyPCYikkCAz7zRBc25iWtaXODvYnDCyc4vwVg38
> > QsNfXvOsSrnE80WOQxXKbaHutMaf8QoiNQ5+M8gMNKWAHXZ0ROYgAE9lm2QfLMTE
> > oidjVh9WrYmlXCmJl0pgFdN1Dc5J+KimoTK8ttvGcweRckUdgkBRQsmyqILtn+ql
> > peNN9QU5W1V8rUfliTq9XCXDu1rAKuKtSPb3GQD9vXDQ22QSHQqjk8eLdd2bAK1n
> > ji/r+Bjp9XNLvySaPi9neiEp3geFjZnN7b3pC2QtDsRJozv6prliNHOsGgLin5dN
> > FmrwSXysha7hZtxy3ze4XnMa/91GZPB9Z91hZdALXyVSbDBrE4ukUABprI6tK8/6
> > O2pfmsdWzvGMNgXFibg1sgJk9e8aTvp6YPyi6Xyj/88hLD6YxB3/ekxxBy00EDW/
> > RFqKfswkYKypfKwx0FXq
> > =8Rg1
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> ___________________________________________________________
> This email has been scanned by MessageLabs' Email Security
> System on behalf of the University of Brighton.
> For more information see http://www.brighton.ac.uk/is/spam/
> ___________________________________________________________

___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/05b96056/attachment.html>

From metaniklas at gmail.com  Tue Sep  8 14:35:16 2015
From: metaniklas at gmail.com (Niklas Larsson)
Date: Tue, 8 Sep 2015 16:35:16 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
Message-ID: <55eef223.68ac700a.8849f.3c11@mx.google.com>

I would be unhappy if GHC included gratuitous differences from the Haskell spec by default. It's hard enough for people working on alternative Haskell implementations as is, stepping away from the spec would be a movie in the wrong direction.

----- Ursprungligt meddelande -----
Fr?n: "Michal Antkiewicz" <mantkiew at gsd.uwaterloo.ca>
Skickat: ?2015-?09-?08 16:10
Till: "Haskell Cafe" <haskell-cafe at haskell.org>
?mne: Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock

+1 for the change but not for an extension. Here's why


1. I remember when I was new to Haskell, having to add $ confused me a lot. It caused a lot of frustration, some errors I didn't understand, which didn't help me realize that $ was needed. I still vividly remember the pain....


2. It seems the change is fully backwards compatible and it does not prevent people still using the old style if they wanted. I would make it a default, not an extension.


3. In order to verify backwards compatibility, I would generate Core output for all of Hackage with both the current and the new compilers and check that Core remains identical. That would be a conclusive proof to me.


4. Regarding the other mentioned extensions like multiway if, etc. they should become default as well because they are backwards compatible as well. 


5. The only reason to guard changes behind LANGUAGE pragmas should be when they are causing problems with other extensions.


I too feel that Haskell community is becoming more and more conservative. I believe there's still time now to make the language as best it can be at the cost of loosing backwards compatibility. The rapid improvements in the language is what attracts me to Haskell.


Best,

Micha? 


On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <andrew.gibiansky at gmail.com> wrote:

In order to get a feel for  using this extension in real-world Haskell, take a look at the new ghc-reskin package:


https://github.com/gibiansky/ghc-reskin



This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example.


-- Andrew


On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net> wrote:

On 09/08/2015 03:08 AM, Dan Burton wrote:
> +1 people who like it can use it and people who don't like it don't have to
> use it. Personally I wish it were the default because the superfluous $
> confuses a lot of people coming from other languages like Ruby.
>

Whether it's "superfluous" depends entirely on one's PoV.

> You can even write in the old style if you have the extension turned on. It
> doesn't disable the old way of doing things. It just allows a new way. It's
> entirely backwards compatible with working code when turned on, is it not?
>

Except now there are two "dialects" everybody has to read/understand.
That's not progress IMO. (Considering that it's so little gain. I really
don't understand the hatred of $ that some people seem to have.)

Regards,



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/281da55f/attachment.html>

From acowley at seas.upenn.edu  Tue Sep  8 14:46:12 2015
From: acowley at seas.upenn.edu (Anthony Cowley)
Date: Tue, 8 Sep 2015 10:46:12 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
Message-ID: <CADch-tJbf5wL+TYbVMmRL+W0+3AMcFRpsBvhTJJSq75zw4kH3A@mail.gmail.com>

On Tuesday, September 8, 2015, Michal Antkiewicz <mantkiew at gsd.uwaterloo.ca>
wrote:

> +1 for the change but not for an extension. Here's why
>
> 2. It seems the change is fully backwards compatible and it does not
> prevent people still using the old style if they wanted. I would make it a
> default, not an extension.
>
> 4. Regarding the other mentioned extensions like multiway if, etc. they
> should become default as well because they are backwards compatible as
> well.
>
> 5. The only reason to guard changes behind LANGUAGE pragmas should be when
> they are causing problems with other extensions.
>
> I too feel that Haskell community is becoming more and more conservative.
> I believe there's still time now to make the language as best it can be at
> the cost of loosing backwards compatibility. The rapid improvements in the
> language is what attracts me to Haskell.
>
> Best,
> Micha?
>

I'm +1 on the proposal now, too. I was previously ambivalent because, like
most folks on the list, I'm used to reading $. But looking at the examples,
I think I'm capable of adapting, and they do look fine to me. Lambdas
creating a block is traditional in some notations, and this change just
causes Haskell to lean on white space sensitivity a bit more.

I also agree with Micha?. Death by a thousand extensions is a silly lapse
of self-care. We're held hostage by a process that doesn't actually exist,
and would be better served if backwards compatible changes didn't require
undue ceremony to invoke.

Anthony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/0d2726d2/attachment.html>

From ekmett at gmail.com  Tue Sep  8 14:54:09 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 8 Sep 2015 10:54:09 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
Message-ID: <CAJumaK9Vg0=5Qy7gkf0u6tZ8LBV=eDm02hANbc3vF6U6vfQoOw@mail.gmail.com>

On Tue, Sep 8, 2015 at 10:10 AM, Michal Antkiewicz <
mantkiew at gsd.uwaterloo.ca> wrote:

> +1 for the change but not for an extension. Here's why
>
> 5. The only reason to guard changes behind LANGUAGE pragmas should be when
> they are causing problems with other extensions.
>

There is a massive downside to this view. It only permits monotonic
progress in one direction. If we later learn about a better thing we could
have done, you can never really retract it.

There are a lot of historically proposed extensions that 'don't break
anything' that you've never heard of that subtly conflict with other
extensions that 'don't break anything'.

Trex-records, half a dozen layout rule variants, I don't know how to
resolve both naked existential types in UHC and type families in GHC...

Each of these chip away at some innocuous corner of our syntax or
semantics, but in aggregate they'd leave us no room to grow, and no ability
to know if we'd written portable, standards compliant, code.

The LANGUAGE pragma is an annoying tax, but I think the long term benefits
in terms of readability of new extensions makes it worth it. Look at
languages like C++ and what horrible things they have to call everything to
avoid conflicting with every random historical idea baked into the
standard. Let's not go down that road.

You can always amortize the cost of those LANGUAGE pragmas by embedding
them in the extensions field of your cabal file if you feel they must be on
at all times in the code you write -- and since the ones you are interested
in are 'just extensions that don't break anything' this causes you no pain
when reading other people's code as they just don't use your favorite
extension.

-Edward

Best,
> Micha?
>
> On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> In order to get a feel for  using this extension in real-world Haskell,
>> take a look at the new ghc-reskin package:
>>
>> https://github.com/gibiansky/ghc-reskin
>>
>> This allows you to use ArgumentBlock *today* by passing GHC a few
>> parameters to tell it to use ghc-reskin as a preprocessor. Take a look at
>> the README for a full example.
>>
>> -- Andrew
>>
>> On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net>
>> wrote:
>>
>>> On 09/08/2015 03:08 AM, Dan Burton wrote:
>>> > +1 people who like it can use it and people who don't like it don't
>>> have to
>>> > use it. Personally I wish it were the default because the superfluous $
>>> > confuses a lot of people coming from other languages like Ruby.
>>> >
>>>
>>> Whether it's "superfluous" depends entirely on one's PoV.
>>>
>>> > You can even write in the old style if you have the extension turned
>>> on. It
>>> > doesn't disable the old way of doing things. It just allows a new way.
>>> It's
>>> > entirely backwards compatible with working code when turned on, is it
>>> not?
>>> >
>>>
>>> Except now there are two "dialects" everybody has to read/understand.
>>> That's not progress IMO. (Considering that it's so little gain. I really
>>> don't understand the hatred of $ that some people seem to have.)
>>>
>>> Regards,
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/cde1f691/attachment-0001.html>

From mantkiew at gsd.uwaterloo.ca  Tue Sep  8 14:55:37 2015
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Tue, 8 Sep 2015 10:55:37 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55eef223.68ac700a.8849f.3c11@mx.google.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
Message-ID: <CAGW9QSzdGpipNBZ-XRevC77LNafx3BwPhifVp=Lgbu=+CB1oNw@mail.gmail.com>

"The spec"... Maybe we need a more lightweight process:

Every two years, a committee gathers and issues a statement:

"Haskell 2016 includes the following extensions by default: <list>". And
remove the corresponding language pragmas.

And we call that the new spec, that's it.

There's no point in holding off everybody down to Haskell 2010. Haskell' is
dead, nobody works on the full-blown spec, etc.

There's a wide consensus in the community about certain extensions. Let's
just make them default for the benefit of all (or at least the vast
majority).

Micha?

On Tue, Sep 8, 2015 at 10:35 AM, Niklas Larsson <metaniklas at gmail.com>
wrote:

> I would be unhappy if GHC included gratuitous differences from the Haskell
> spec by default. It's hard enough for people working on alternative Haskell
> implementations as is, stepping away from the spec would be a movie in the
> wrong direction.
> ------------------------------
> Fr?n: Michal Antkiewicz <mantkiew at gsd.uwaterloo.ca>
> Skickat: ?2015-?09-?08 16:10
> Till: Haskell Cafe <haskell-cafe at haskell.org>
> ?mne: Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
>
> +1 for the change but not for an extension. Here's why
>
> 1. I remember when I was new to Haskell, having to add $ confused me a
> lot. It caused a lot of frustration, some errors I didn't understand, which
> didn't help me realize that $ was needed. I still vividly remember the
> pain....
>
> 2. It seems the change is fully backwards compatible and it does not
> prevent people still using the old style if they wanted. I would make it a
> default, not an extension.
>
> 3. In order to verify backwards compatibility, I would generate Core
> output for all of Hackage with both the current and the new compilers and
> check that Core remains identical. That would be a conclusive proof to me.
>
> 4. Regarding the other mentioned extensions like multiway if, etc. they
> should become default as well because they are backwards compatible as
> well.
>
> 5. The only reason to guard changes behind LANGUAGE pragmas should be when
> they are causing problems with other extensions.
>
> I too feel that Haskell community is becoming more and more conservative.
> I believe there's still time now to make the language as best it can be at
> the cost of loosing backwards compatibility. The rapid improvements in the
> language is what attracts me to Haskell.
>
> Best,
> Micha?
>
> On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> In order to get a feel for  using this extension in real-world Haskell,
>> take a look at the new ghc-reskin package:
>>
>> https://github.com/gibiansky/ghc-reskin
>>
>> This allows you to use ArgumentBlock *today* by passing GHC a few
>> parameters to tell it to use ghc-reskin as a preprocessor. Take a look at
>> the README for a full example.
>>
>> -- Andrew
>>
>> On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net>
>> wrote:
>>
>>> On 09/08/2015 03:08 AM, Dan Burton wrote:
>>> > +1 people who like it can use it and people who don't like it don't
>>> have to
>>> > use it. Personally I wish it were the default because the superfluous $
>>> > confuses a lot of people coming from other languages like Ruby.
>>> >
>>>
>>> Whether it's "superfluous" depends entirely on one's PoV.
>>>
>>> > You can even write in the old style if you have the extension turned
>>> on. It
>>> > doesn't disable the old way of doing things. It just allows a new way.
>>> It's
>>> > entirely backwards compatible with working code when turned on, is it
>>> not?
>>> >
>>>
>>> Except now there are two "dialects" everybody has to read/understand.
>>> That's not progress IMO. (Considering that it's so little gain. I really
>>> don't understand the hatred of $ that some people seem to have.)
>>>
>>> Regards,
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/7be425a3/attachment.html>

From ekmett at gmail.com  Tue Sep  8 15:12:28 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 8 Sep 2015 11:12:28 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGW9QSzdGpipNBZ-XRevC77LNafx3BwPhifVp=Lgbu=+CB1oNw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
 <CAGW9QSzdGpipNBZ-XRevC77LNafx3BwPhifVp=Lgbu=+CB1oNw@mail.gmail.com>
Message-ID: <CAJumaK_FOh39b8E7T=O7AQ0pishwWXs7UjojGCrciweU5uHOXQ@mail.gmail.com>

On Tue, Sep 8, 2015 at 10:55 AM, Michal Antkiewicz <
mantkiew at gsd.uwaterloo.ca> wrote:

> "The spec"... Maybe we need a more lightweight process:
>
> Every two years, a committee gathers and issues a statement:
>
> "Haskell 2016 includes the following extensions by default: <list>". And
> remove the corresponding language pragmas.
>

I have no objection to adding such extensions we find warranted to
Haskell201X, merely to their willy nilly addition to the language without a
pragma outside of any such a process.

Even for the bits included in Haskell2010 we didn't remove the
corresponding LANGUAGE pragmas from existence, merely specified that when
you are using {-# LANGUAGE Haskell2010 #-} or tell cabal to use
default-language: Haskell2010 then they turn on by default.


> There's no point in holding off everybody down to Haskell 2010. Haskell'
> is dead, nobody works on the full-blown spec, etc.
>

Herbert is in the middle of rebooting the Haskell' process, I wouldn't
count it out yet.

-Edward



> There's a wide consensus in the community about certain extensions. Let's
> just make them default for the benefit of all (or at least the vast
> majority).
>
> Micha?
>
> On Tue, Sep 8, 2015 at 10:35 AM, Niklas Larsson <metaniklas at gmail.com>
> wrote:
>
>> I would be unhappy if GHC included gratuitous differences from the
>> Haskell spec by default. It's hard enough for people working on alternative
>> Haskell implementations as is, stepping away from the spec would be a movie
>> in the wrong direction.
>> ------------------------------
>> Fr?n: Michal Antkiewicz <mantkiew at gsd.uwaterloo.ca>
>> Skickat: ?2015-?09-?08 16:10
>> Till: Haskell Cafe <haskell-cafe at haskell.org>
>> ?mne: Re: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
>>
>> +1 for the change but not for an extension. Here's why
>>
>> 1. I remember when I was new to Haskell, having to add $ confused me a
>> lot. It caused a lot of frustration, some errors I didn't understand, which
>> didn't help me realize that $ was needed. I still vividly remember the
>> pain....
>>
>> 2. It seems the change is fully backwards compatible and it does not
>> prevent people still using the old style if they wanted. I would make it a
>> default, not an extension.
>>
>> 3. In order to verify backwards compatibility, I would generate Core
>> output for all of Hackage with both the current and the new compilers and
>> check that Core remains identical. That would be a conclusive proof to me.
>>
>> 4. Regarding the other mentioned extensions like multiway if, etc. they
>> should become default as well because they are backwards compatible as
>> well.
>>
>> 5. The only reason to guard changes behind LANGUAGE pragmas should be
>> when they are causing problems with other extensions.
>>
>> I too feel that Haskell community is becoming more and more conservative.
>> I believe there's still time now to make the language as best it can be at
>> the cost of loosing backwards compatibility. The rapid improvements in the
>> language is what attracts me to Haskell.
>>
>> Best,
>> Micha?
>>
>> On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <
>> andrew.gibiansky at gmail.com> wrote:
>>
>>> In order to get a feel for  using this extension in real-world Haskell,
>>> take a look at the new ghc-reskin package:
>>>
>>> https://github.com/gibiansky/ghc-reskin
>>>
>>> This allows you to use ArgumentBlock *today* by passing GHC a few
>>> parameters to tell it to use ghc-reskin as a preprocessor. Take a look at
>>> the README for a full example.
>>>
>>> -- Andrew
>>>
>>> On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <spam at scientician.net>
>>> wrote:
>>>
>>>> On 09/08/2015 03:08 AM, Dan Burton wrote:
>>>> > +1 people who like it can use it and people who don't like it don't
>>>> have to
>>>> > use it. Personally I wish it were the default because the superfluous
>>>> $
>>>> > confuses a lot of people coming from other languages like Ruby.
>>>> >
>>>>
>>>> Whether it's "superfluous" depends entirely on one's PoV.
>>>>
>>>> > You can even write in the old style if you have the extension turned
>>>> on. It
>>>> > doesn't disable the old way of doing things. It just allows a new
>>>> way. It's
>>>> > entirely backwards compatible with working code when turned on, is it
>>>> not?
>>>> >
>>>>
>>>> Except now there are two "dialects" everybody has to read/understand.
>>>> That's not progress IMO. (Considering that it's so little gain. I really
>>>> don't understand the hatred of $ that some people seem to have.)
>>>>
>>>> Regards,
>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/65ebcf38/attachment.html>

From eir at cis.upenn.edu  Tue Sep  8 15:12:19 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 8 Sep 2015 11:12:19 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGW9QSzdGpipNBZ-XRevC77LNafx3BwPhifVp=Lgbu=+CB1oNw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@ma!
 il.gmail.com> <55eef223.68ac700a.8849f.3c11@mx.google.com>
 <CAGW9QSzdGpipNBZ-XRevC77LNafx3BwPhifVp=Lgbu=+CB1oNw@mail.gmail.com>
Message-ID: <E87627E2-AC98-434F-BC4D-268327F3B946@cis.upenn.edu>

I'm quite ambivalent on this proposal. But I think that it makes the language *more* regular, not less: Look at https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003, the Haskell 2010 Report on expression syntax. This proposal (if we include `if`, `let`, and `case`, along with `\` and `do`, which would seem to make it more consistent) amounts to dropping the /lexp/ nonterminal and combining it with /aexp/. Simple! You have to add "Lambdas and `else` clauses extend as far to the right as possible (not taking fixities into account)" but we already have that.

So I don't think that arguments against this proposal that make claims about regularity, or lack thereof, really stand close scrutiny.

Richard

From silvio.frischi at gmail.com  Tue Sep  8 15:16:43 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Tue, 8 Sep 2015 17:16:43 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55EEEE1F.6050909@plaimi.net>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55EEEE1F.6050909@plaimi.net>
Message-ID: <55EEFBDB.30904@gmail.com>

> Anything that is not Haskell 2010 is *by definition* a language 
> extension. If you want to change the language, that is a discussion
>  for Haskell' not GHC.

I'm not sure this is entirely true. In ghc file
compiler/parser/Lexer.x it is stated.

-- Pushing a new implicit layout context.  If the indentation of the
-- next token is not greater than the previous layout context, then
-- Haskell 98 says that the new layout context should be empty; that is
-- the lexer must generate {}.
--
-- We are slightly more lenient than this: when the new context is start
ed
-- by a 'do', then we allow the new context to be at the same
indentation as
-- the previous context.  This is what the 'strict' argument is for.

I think this means that the following is valid in ghc but not in
haskell 98/2010.

main :: IO ()
main = do
    if True
        then return ()
        else do
    return ()

Silvio

From mantkiew at gsd.uwaterloo.ca  Tue Sep  8 15:18:38 2015
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Tue, 8 Sep 2015 11:18:38 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJumaK_FOh39b8E7T=O7AQ0pishwWXs7UjojGCrciweU5uHOXQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
 <CAGW9QSzdGpipNBZ-XRevC77LNafx3BwPhifVp=Lgbu=+CB1oNw@mail.gmail.com>
 <CAJumaK_FOh39b8E7T=O7AQ0pishwWXs7UjojGCrciweU5uHOXQ@mail.gmail.com>
Message-ID: <CAGW9QSwSQccT6im05EG8fjhSzjfcAycCPC90GNiy_wDw16FwrQ@mail.gmail.com>

>
>
>> "Haskell 2016 includes the following extensions by default: <list>". And
>> remove the corresponding language pragmas.
>>
>
> I have no objection to adding such extensions we find warranted to
> Haskell201X, merely to their willy nilly addition to the language without a
> pragma outside of any such a process.
>
> Even for the bits included in Haskell2010 we didn't remove the
> corresponding LANGUAGE pragmas from existence, merely specified that when
> you are using {-# LANGUAGE Haskell2010 #-} or tell cabal to use
> default-language: Haskell2010 then they turn on by default.
>

Ah, sure, yes, they should be kept. I don't care about removing them.
However, perhaps after some long time (10 years, 15..?) maybe some garbage
collection of unused pragmas could be done. The same way we remove old CPP
IFDEFs when we no longer need to support the old compiler or library
version. This just reduces the complexity of the code.


>
>> There's no point in holding off everybody down to Haskell 2010. Haskell'
>> is dead, nobody works on the full-blown spec, etc.
>>
>
> Herbert is in the middle of rebooting the Haskell' process, I wouldn't
> count it out yet.
>

:-) That's great to hear!

Micha?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/95132980/attachment.html>

From ekmett at gmail.com  Tue Sep  8 15:31:00 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 8 Sep 2015 11:31:00 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGW9QSwSQccT6im05EG8fjhSzjfcAycCPC90GNiy_wDw16FwrQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
 <CAGW9QSzdGpipNBZ-XRevC77LNafx3BwPhifVp=Lgbu=+CB1oNw@mail.gmail.com>
 <CAJumaK_FOh39b8E7T=O7AQ0pishwWXs7UjojGCrciweU5uHOXQ@mail.gmail.com>
 <CAGW9QSwSQccT6im05EG8fjhSzjfcAycCPC90GNiy_wDw16FwrQ@mail.gmail.com>
Message-ID: <CAJumaK-dBnhDeQAXgA1j55JKkwQjB9=MCGFF0rpRFSh44vn_wA@mail.gmail.com>

On Tue, Sep 8, 2015 at 11:18 AM, Michal Antkiewicz <
mantkiew at gsd.uwaterloo.ca> wrote:
>
>
> Ah, sure, yes, they should be kept. I don't care about removing them.
> However, perhaps after some long time (10 years, 15..?) maybe some garbage
> collection of unused pragmas could be done. The same way we remove old CPP
> IFDEFs when we no longer need to support the old compiler or library
> version. This just reduces the complexity of the code.
>

Doing so would basically rule out compiling versions of the language that
predates the cleanup. Given that I don't see GHC dropping support for
Haskell98 any time soon, this seems more or less an academic concern, or
one for far flung future generations of Haskellers. =)

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/75167038/attachment.html>

From roma at ro-che.info  Tue Sep  8 16:28:42 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 8 Sep 2015 19:28:42 +0300
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55EEFBDB.30904@gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55EEEE1F.6050909@plaimi.net> <55EEFBDB.30904@gmail.com>
Message-ID: <55EF0CBA.3090600@ro-che.info>

On 08/09/15 18:16, Silvio Frischknecht wrote:
>> Anything that is not Haskell 2010 is *by definition* a language 
>> extension. If you want to change the language, that is a discussion
>>  for Haskell' not GHC.
> 
> I'm not sure this is entirely true. In ghc file
> compiler/parser/Lexer.x it is stated.
> 
> -- Pushing a new implicit layout context.  If the indentation of the
> -- next token is not greater than the previous layout context, then
> -- Haskell 98 says that the new layout context should be empty; that is
> -- the lexer must generate {}.
> --
> -- We are slightly more lenient than this: when the new context is start
> ed
> -- by a 'do', then we allow the new context to be at the same
> indentation as
> -- the previous context.  This is what the 'strict' argument is for.
> 
> I think this means that the following is valid in ghc but not in
> haskell 98/2010.
> 
> main :: IO ()
> main = do
>     if True
>         then return ()
>         else do
>     return ()

That's still an extension (-XNondecreasingIndentation), just one enabled
by default.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/04844fe2/attachment.sig>

From silvio.frischi at gmail.com  Tue Sep  8 16:39:33 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Tue, 8 Sep 2015 18:39:33 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55EF0CBA.3090600@ro-che.info>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55EEEE1F.6050909@plaimi.net> <55EEFBDB.30904@gmail.com>
 <55EF0CBA.3090600@ro-che.info>
Message-ID: <55EF0F45.4050605@gmail.com>

> That's still an extension (-XNondecreasingIndentation), just one enabled
> by default.

Interesting. Is there a list of extensions that are enabled by default?
I'm sure whoever suggested it as default and not extension will be happy
with this too.


BTW, +1 from me for the proposal.

Silvio

From kyle.marek.spartz at gmail.com  Tue Sep  8 16:46:06 2015
From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz)
Date: Tue, 08 Sep 2015 11:46:06 -0500
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
Message-ID: <2fcp3sa8sw3lm9.fsf@gmail.com>

Not sure about that. $ isn't syntax. It's defined in terms of the
language.

($) :: (a -> b) -> a -> b
f $ x =  f x

If we didn't have the $ operator, we'd make it ourselves.


Alexey Vagarenko writes:

> Consider this.
> If we didn't have $ operator in the first place, we'd use parentheses
> everywhere:
>
>     foo (bar (baz (qux (quux (do a <- b; return a)))))
> under your proposal it turns to:
>     foo (bar (baz (qux (quux do a <- b; return a))))
>
> another example:
>     foo (bar baz) (qux quux) (do a <- b; return a)
> turns to :
>     foo (bar baz) (qux quux) do a <- b; return a
>
> with lambdas:
>     foo (bar baz) (qux quux) (\x -> x)
> to:
>     foo (bar baz) (qux quux) \x -> x
>
> Can't you see your proposal makes things *less *consistent, *not more*?
> -1.
>
> 2015-09-07 0:03 GMT+06:00 Oliver Charles <ollie at ocharles.org.uk>:
>
>> I mean that people us $ for purely syntactical purposes. If an editor is
>> going to make refactorings and retain a certain sense of style, then the
>> tool needs to know that $ is sometimes to be used. The refactoring (or
>> otherwise) tool now has to be aware of the syntax of Haskell and special
>> symbols in the Prelude.
>>
>> On Sun, Sep 6, 2015 at 6:53 PM Matthew Pickering <
>> matthewtpickering at gmail.com> wrote:
>>
>>> >
>>> > I don't really like $ from an editor perspective though (tooling has to
>>> > become aware of a single function when performing refactorings), so
>>> anything
>>> > that helps reduce how prolific that operator is is a win in my book!
>>> >
>>>
>>> Can you please explain what you mean by this? Is there something more
>>> subtle that $ being a low fixity operator? Which specific problems
>>> does it cause tooling? Are you referring to the fact that there are
>>> problems because $ == id and makes tooling account for two cases when
>>> looking for refactorings? (I'm thinking of hlint here).
>>>
>>> (FWIW, haskell-src-exts tries to fiddle with the AST to account for
>>> fixity after parsing but the GHC parser does not, it happens during
>>> renaming. There is a pure version here[1] if anyone else is in need of
>>> this feature).
>>>
>>> Thanks, Matt
>>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

--
Kyle Marek-Spartz

From targen at gmail.com  Tue Sep  8 16:48:53 2015
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Tue, 8 Sep 2015 12:18:53 -0430
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55eef223.68ac700a.8849f.3c11@mx.google.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
Message-ID: <CAJWnFaPnzfTfkRjm8MR1ZcmX6=bpxY3ojO34N2uOTPB+aC9Huw@mail.gmail.com>

(Resending; forgot to include the list.  Sorry for the noise, Niklas.)

On Tue, Sep 8, 2015 at 10:05 AM, Niklas Larsson <metaniklas at gmail.com> wrote:
> I would be unhappy if GHC included gratuitous differences from the Haskell
> spec by default.

You must be quite unhappy.  From the GHC user manual:

?7.3.1. Unicode syntax: The language extension `-XUnicodeSyntax`
enables Unicode characters to be used to stand for certain ASCII
character sequences.

?7.3.2. The magic hash: The language extension `-XMagicHash` allows
`#` as a postfix modifier to identifiers. Thus, `x#` is a valid
variable, and `T#` is a valid type constructor or data constructor.
The hash sign does not change semantics at all.

?7.3.3. Negative literals: The literal `-123` is, according to
Haskell98 and Haskell 2010, desugared as `negate (fromInteger 123)`.
The language extension `-XNegativeLiterals` means that it is instead
desugared as `fromInteger (-123)`.

?7.3.4. Fractional looking integer literals: Haskell 2010 and Haskell
98 define floating literals with the syntax `1.2e6`. These literals
have the type `Fractional a => a`.  The language extension
`-XNumDecimals` allows you to also use the floating literal syntax for
instances of `Integral`, and have values like `(1.2e6 :: Num a => a)`.

?7.3.5. Binary integer literals: Haskell 2010 and Haskell 98 allows
for integer literals to be given in decimal, octal (prefixed by `0o`
or `0O`), or hexadecimal notation (prefixed by `0x` or `0X`).  The
language extension `-XBinaryLiterals` adds support for expressing
integer literals in binary notation with the prefix `0b` or `0B`. For
instance, the binary integer literal `0b11001001` will be desugared
into `fromInteger 201` when `-XBinaryLiterals` is enabled.

?7.3.10. `n+k` patterns: `n+k` pattern support is disabled by default.
To enable it, you can use the `-XNPlusKPatterns` flag.

?7.3.17. Postfix operators: The `-XPostfixOperators` flag enables a
small extension to the syntax of left operator sections, which allows
you to define postfix operators. The extension is this: the left
section `(e !)` is equivalent (from the point of view of both type
checking and execution) to the expression `((!) e)` (for any
expression `e` and operator `(!)`.  The strict Haskell 98
interpretation is that the section is equivalent to `(\y -> (!) e y)`.
That is, the operator must be a function of two arguments. GHC allows
it to take only one argument, and that in turn allows you to write the
function postfix.

?7.3.18. Tuple sections: The `-XTupleSections` flag enables
Python-style partially applied tuple constructors. For example, the
following program, `(, True)`, is considered to be an alternative
notation for the more unwieldy alternative `\x -> (x, True)`.

?7.3.19. Lambda-case: The `-XLambdaCase` flag enables expressions of
the form `\case { p1 -> e1; ...; pN -> eN }` which is equivalent to
`\freshName -> case freshName of { p1 -> e1; ...; pN -> eN }`

?7.3.20. Empty case alternatives: The `-XEmptyCase` flag enables case
expressions, or lambda-case expressions, that have no alternatives,
thus: `case e of { }`

?7.3.21. Multi-way if-expressions: With `-XMultiWayIf` flag GHC
accepts conditional expressions with multiple branches: `if | guard1
-> expr1 ; | ... ; | guardN -> exprN`, which is roughly equivalent to
`case () of _ | guard1 -> expr1 ; ... ; _ | guardN -> exprN`.

?7.3.23. Record puns: Record puns are enabled by the flag
`-XNamedFieldPuns`.  When using records, it is common to write a
pattern that binds a variable with the same name as a record field,
such as: `data C = C {a :: Int}; f (C {a = a}) = a`.  Record punning
permits the variable name to be elided, so one can simply write `f (C
{a}) = a` to mean the same pattern as above.

?7.3.24. Record wildcards: Record wildcards are enabled by the flag
`-XRecordWildCards`. [?]  For records with many fields, it can be
tiresome to write out each field individually in a record pattern, as
in `data C = C {a :: Int, b :: Int, c :: Int, d :: Int}; f (C {a = 1,
b = b, c = c, d = d}) = b + c + d`.  Record wildcard syntax permits a
`..` in a record pattern, where each elided field `f` is replaced by
the pattern `f = f`.

?7.6.4. Overloaded string literals: GHC supports overloaded string
literals. Normally a string literal has type `String`, but with
overloaded string literals enabled (with `-XOverloadedStrings`) a
string literal has type `(IsString a) => a`.  This means that the
usual string syntax can be used, e.g., for `ByteString`, `Text`, and
other variations of string like types.

?7.6.5. Overloaded lists: GHC supports overloading of the list
notation. [?]  This extension allows programmers to use the list
notation for construction of structures like: `Set`, `Map`, `IntMap`,
`Vector`, `Text` and `Array`.

Please, let?s not pretend there is anything extraordinary about GHC
extensions straying from the Haskell standards for mostly syntactical
reasons that could be convincingly argued to be gratuitous.  We have
plenty of that.  We have always had plenty of that.  Having plenty of
that has been significant in making Haskell a pleasant environment for
formal expression.

Support for stylistic diversity is a feature, not a bug.

From allbery.b at gmail.com  Tue Sep  8 16:54:23 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 8 Sep 2015 12:54:23 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJWnFaPnzfTfkRjm8MR1ZcmX6=bpxY3ojO34N2uOTPB+aC9Huw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
 <CAJWnFaPnzfTfkRjm8MR1ZcmX6=bpxY3ojO34N2uOTPB+aC9Huw@mail.gmail.com>
Message-ID: <CAKFCL4UyAu4Ds4akYrmEQXduL+d5JsMHcbG_EcnmMdH6dkoWDQ@mail.gmail.com>

On Tue, Sep 8, 2015 at 12:48 PM, Manuel G?mez <targen at gmail.com> wrote:

> You must be quite unhappy.  From the GHC user manual:


Most of that list is *not* enabled by default, which was the specific
assertion. AFAIK the only one that is is NondecreasingIndentation, and that
one is more or less grandfathered because it's too late to change. (I also
suspect it is top of the list for a next version of the Haskell standard.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/e8597b59/attachment.html>

From vivitsu.maharaja at gmail.com  Tue Sep  8 16:55:54 2015
From: vivitsu.maharaja at gmail.com (Vivitsu Maharaja)
Date: Tue, 08 Sep 2015 16:55:54 +0000
Subject: [Haskell-cafe] Functional counterpart of counting-sort?
In-Reply-To: <5763C5DB-3285-4373-96E7-DB952F935A10@gmail.com>
References: <853881CA-AAAA-414F-A34D-4C6B8CB55E24@gmail.com>
 <20150906173636.GK14413@weber>
 <5763C5DB-3285-4373-96E7-DB952F935A10@gmail.com>
Message-ID: <CA+Gb7UOaVUSXbufYh=TXMw+x1kQww-O4JdgpLgw7T=k1L+Lk1g@mail.gmail.com>

This video should help in explaining what the library is about. It's a talk
by Edward Kmett, the author of the library, and he goes into the motivation
and internals of the library:

https://youtu.be/cB8DapKQz-I

Don't worry if you don't get everything in the first watch though, I've
watched it a couple of times, and have still worked my way through only the
first half of it, maybe ;)

Reading the papers before hand might help too.

Enjoy!
Vivitsu
On Sun, Sep 6, 2015 at 23:33 Nicola Gigante <nicola.gigante at gmail.com>
wrote:

> Il giorno 06/set/2015, alle ore 19:36, Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> ha scritto:
> >
> >> On Sun, Sep 06, 2015 at 07:29:23PM +0200, Nicola Gigante wrote:
> >> Do any of you know if it is possible to sort a _list_ of integers in
> >> O(n) time in a (lazy) purely functional language?
> >
> > Are you familiar with discrimination?
> >
> >    http://hackage.haskell.org/package/discrimination
> >
>
> Well, no, I wasn't aware of it at all! Thank you!
>
> It seems what I'm looking for!
> I'll read the papers pointed in the doc, but does anyone have a few
> words to say on what "discrimination" is all about?
>
> Greetings,
> Nicola
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/cef27886/attachment.html>

From matthewtpickering at gmail.com  Tue Sep  8 17:01:14 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 8 Sep 2015 19:01:14 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJWnFaPnzfTfkRjm8MR1ZcmX6=bpxY3ojO34N2uOTPB+aC9Huw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
 <CAJWnFaPnzfTfkRjm8MR1ZcmX6=bpxY3ojO34N2uOTPB+aC9Huw@mail.gmail.com>
Message-ID: <CALuQ0m8-KnY1ntPrJMhiZ+LmHcm9Q4XrSnwN8u6WcNhwN=LpNw@mail.gmail.com>

Here is a slightly outdated list of how many packages use which
extensions. http://mpickering.github.io/extensions

As you can see there are only a few defaults.

Matt

On Tue, Sep 8, 2015 at 6:48 PM, Manuel G?mez <targen at gmail.com> wrote:
> (Resending; forgot to include the list.  Sorry for the noise, Niklas.)
>
> On Tue, Sep 8, 2015 at 10:05 AM, Niklas Larsson <metaniklas at gmail.com> wrote:
>> I would be unhappy if GHC included gratuitous differences from the Haskell
>> spec by default.
>
> You must be quite unhappy.  From the GHC user manual:
>
> ?7.3.1. Unicode syntax: The language extension `-XUnicodeSyntax`
> enables Unicode characters to be used to stand for certain ASCII
> character sequences.
>
> ?7.3.2. The magic hash: The language extension `-XMagicHash` allows
> `#` as a postfix modifier to identifiers. Thus, `x#` is a valid
> variable, and `T#` is a valid type constructor or data constructor.
> The hash sign does not change semantics at all.
>
> ?7.3.3. Negative literals: The literal `-123` is, according to
> Haskell98 and Haskell 2010, desugared as `negate (fromInteger 123)`.
> The language extension `-XNegativeLiterals` means that it is instead
> desugared as `fromInteger (-123)`.
>
> ?7.3.4. Fractional looking integer literals: Haskell 2010 and Haskell
> 98 define floating literals with the syntax `1.2e6`. These literals
> have the type `Fractional a => a`.  The language extension
> `-XNumDecimals` allows you to also use the floating literal syntax for
> instances of `Integral`, and have values like `(1.2e6 :: Num a => a)`.
>
> ?7.3.5. Binary integer literals: Haskell 2010 and Haskell 98 allows
> for integer literals to be given in decimal, octal (prefixed by `0o`
> or `0O`), or hexadecimal notation (prefixed by `0x` or `0X`).  The
> language extension `-XBinaryLiterals` adds support for expressing
> integer literals in binary notation with the prefix `0b` or `0B`. For
> instance, the binary integer literal `0b11001001` will be desugared
> into `fromInteger 201` when `-XBinaryLiterals` is enabled.
>
> ?7.3.10. `n+k` patterns: `n+k` pattern support is disabled by default.
> To enable it, you can use the `-XNPlusKPatterns` flag.
>
> ?7.3.17. Postfix operators: The `-XPostfixOperators` flag enables a
> small extension to the syntax of left operator sections, which allows
> you to define postfix operators. The extension is this: the left
> section `(e !)` is equivalent (from the point of view of both type
> checking and execution) to the expression `((!) e)` (for any
> expression `e` and operator `(!)`.  The strict Haskell 98
> interpretation is that the section is equivalent to `(\y -> (!) e y)`.
> That is, the operator must be a function of two arguments. GHC allows
> it to take only one argument, and that in turn allows you to write the
> function postfix.
>
> ?7.3.18. Tuple sections: The `-XTupleSections` flag enables
> Python-style partially applied tuple constructors. For example, the
> following program, `(, True)`, is considered to be an alternative
> notation for the more unwieldy alternative `\x -> (x, True)`.
>
> ?7.3.19. Lambda-case: The `-XLambdaCase` flag enables expressions of
> the form `\case { p1 -> e1; ...; pN -> eN }` which is equivalent to
> `\freshName -> case freshName of { p1 -> e1; ...; pN -> eN }`
>
> ?7.3.20. Empty case alternatives: The `-XEmptyCase` flag enables case
> expressions, or lambda-case expressions, that have no alternatives,
> thus: `case e of { }`
>
> ?7.3.21. Multi-way if-expressions: With `-XMultiWayIf` flag GHC
> accepts conditional expressions with multiple branches: `if | guard1
> -> expr1 ; | ... ; | guardN -> exprN`, which is roughly equivalent to
> `case () of _ | guard1 -> expr1 ; ... ; _ | guardN -> exprN`.
>
> ?7.3.23. Record puns: Record puns are enabled by the flag
> `-XNamedFieldPuns`.  When using records, it is common to write a
> pattern that binds a variable with the same name as a record field,
> such as: `data C = C {a :: Int}; f (C {a = a}) = a`.  Record punning
> permits the variable name to be elided, so one can simply write `f (C
> {a}) = a` to mean the same pattern as above.
>
> ?7.3.24. Record wildcards: Record wildcards are enabled by the flag
> `-XRecordWildCards`. [?]  For records with many fields, it can be
> tiresome to write out each field individually in a record pattern, as
> in `data C = C {a :: Int, b :: Int, c :: Int, d :: Int}; f (C {a = 1,
> b = b, c = c, d = d}) = b + c + d`.  Record wildcard syntax permits a
> `..` in a record pattern, where each elided field `f` is replaced by
> the pattern `f = f`.
>
> ?7.6.4. Overloaded string literals: GHC supports overloaded string
> literals. Normally a string literal has type `String`, but with
> overloaded string literals enabled (with `-XOverloadedStrings`) a
> string literal has type `(IsString a) => a`.  This means that the
> usual string syntax can be used, e.g., for `ByteString`, `Text`, and
> other variations of string like types.
>
> ?7.6.5. Overloaded lists: GHC supports overloading of the list
> notation. [?]  This extension allows programmers to use the list
> notation for construction of structures like: `Set`, `Map`, `IntMap`,
> `Vector`, `Text` and `Array`.
>
> Please, let?s not pretend there is anything extraordinary about GHC
> extensions straying from the Haskell standards for mostly syntactical
> reasons that could be convincingly argued to be gratuitous.  We have
> plenty of that.  We have always had plenty of that.  Having plenty of
> that has been significant in making Haskell a pleasant environment for
> formal expression.
>
> Support for stylistic diversity is a feature, not a bug.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From kyle.marek.spartz at gmail.com  Tue Sep  8 17:01:22 2015
From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz)
Date: Tue, 08 Sep 2015 12:01:22 -0500
Subject: [Haskell-cafe] Can #Haskell be used to generate the #Java class
	libraries relatively error free? #Java8u60
In-Reply-To: <CAMLKXynUVei6vgwK3JjEYP_UmW9By3i6MKtZhyUr+ifooZmjrA@mail.gmail.com>
References: <CAMLKXynUVei6vgwK3JjEYP_UmW9By3i6MKtZhyUr+ifooZmjrA@mail.gmail.com>
Message-ID: <2fcp3s8u8g3kwt.fsf@gmail.com>

You may be interested in https://github.com/Frege/frege/, a Haskell-like
language for the JVM.

KC writes:

> Can #Haskell be used to generate the #Java class libraries relatively error
> free? #Java8u60
>
> --

--
Kyle Marek-Spartz

From swiesner at lunaryorn.com  Tue Sep  8 17:26:10 2015
From: swiesner at lunaryorn.com (Sebastian Wiesner)
Date: Tue, 8 Sep 2015 19:26:10 +0200
Subject: [Haskell-cafe] emacs haskell-mode with cabal exec,
	test suite sections
In-Reply-To: <55ECA90C.1040104@panix.com>
References: <55ECA90C.1040104@panix.com>
Message-ID: <C3AF1FD8-C2C9-4BBD-B024-474DADBF006B@lunaryorn.com>


> Am 06.09.2015 um 22:58 schrieb Stuart Popejoy <spopejoy at panix.com>:
> 
> I'm having trouble coding test-suite and executable sections with
> the emacs REPL and flycheck.
> 
> 1. cabal-repl can compile against the library code, but fails to see any modules within the non-library section.
> 
> 2. flycheck has the opposite problem: it fails on library module imports but recognizes imports local to the section.
> 
> Note I don't always have these issues, but they seem to crop up whenever I upgrade GHC, or emacs, or haskell-mode, flycheck-haskell etc.
> I'm not sure #1 ever works, but #2 is happening to me on my mac, but not at work on Linux.
> 
> For #1, in the past I've tried a big .dir-locals.el to use `ghci` for the repl and just import everything -- of course losing the nice cabal integration, plus it being slow as molasses to load source files.
> 
> I also briefly investigated modifying haskell-mode to support separate sessions for a given section.
> 
> For #2, flycheck is just a pain to debug, my only recourse is to stick debug output into `flycheck-start-command-checker` to see what commands are going out, and try to troubleshoot.

Do you know about `C-c ! C-c`/`M-x flycheck-compile`?  This shows the command that Flycheck would use and the output it produces.

Can you show your Flycheck/Haskell setup for Emacs, and try to provide more specific details about the errors you see?  At best, please include the output of the above command.

Greetings,
Sebastian


From swiesner at lunaryorn.com  Tue Sep  8 17:27:16 2015
From: swiesner at lunaryorn.com (Sebastian Wiesner)
Date: Tue, 8 Sep 2015 19:27:16 +0200
Subject: [Haskell-cafe] emacs haskell-mode with cabal exec,
	test suite sections
In-Reply-To: <CA+u6gbzUDXeVv42K8NUD7kg=jWtdfme6-5zueWR3qXo23i_3hA@mail.gmail.com>
References: <55ECA90C.1040104@panix.com>
 <CA+u6gbzUDXeVv42K8NUD7kg=jWtdfme6-5zueWR3qXo23i_3hA@mail.gmail.com>
Message-ID: <4D9DA0E3-B558-436D-A23F-460FAFCE3D94@lunaryorn.com>


> Am 07.09.2015 um 00:01 schrieb Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com>:
> 
> On 7 September 2015 at 06:58, Stuart Popejoy <spopejoy at panix.com> wrote:
>> I'm having trouble coding test-suite and executable sections with
>> the emacs REPL and flycheck.
>> 
>> 1. cabal-repl can compile against the library code, but fails to see any
>> modules within the non-library section.
> 
> haskell-session-change-target
> 
>> 
>> 2. flycheck has the opposite problem: it fails on library module imports but
>> recognizes imports local to the section.
> 
> Yeah, it claims to have sandbox support but for some reason I've never
> managed to get it to stop complaining about not being able to find
> modules installed in the sandbox.

Flycheck does not support Cabal sandboxes out of the box.  You need to install and configure the addon package "flycheck-haskell".

From michael at orlitzky.com  Tue Sep  8 17:41:24 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Tue, 8 Sep 2015 13:41:24 -0400
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJWnFaPnzfTfkRjm8MR1ZcmX6=bpxY3ojO34N2uOTPB+aC9Huw@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55eef223.68ac700a.8849f.3c11@mx.google.com>
 <CAJWnFaPnzfTfkRjm8MR1ZcmX6=bpxY3ojO34N2uOTPB+aC9Huw@mail.gmail.com>
Message-ID: <55EF1DC4.1050400@orlitzky.com>

On 09/08/2015 12:48 PM, Manuel G?mez wrote:
> 
> ?7.3.3. Negative literals: The literal `-123` is, according to
> Haskell98 and Haskell 2010, desugared as `negate (fromInteger 123)`.
> The language extension `-XNegativeLiterals` means that it is instead
> desugared as `fromInteger (-123)`.
> 

Totally off-topic, but this is cute =)




From hvr at gnu.org  Tue Sep  8 20:57:03 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 08 Sep 2015 22:57:03 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <55EF0F45.4050605@gmail.com> (Silvio Frischknecht's message of
 "Tue, 8 Sep 2015 18:39:33 +0200")
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55EEEE1F.6050909@plaimi.net> <55EEFBDB.30904@gmail.com>
 <55EF0CBA.3090600@ro-che.info> <55EF0F45.4050605@gmail.com>
Message-ID: <87fv2oy6hs.fsf@gnu.org>

On 2015-09-08 at 18:39:33 +0200, Silvio Frischknecht wrote:
>> That's still an extension (-XNondecreasingIndentation), just one enabled
>> by default.
>
> Interesting. Is there a list of extensions that are enabled by
> default?

https://github.com/ghc/ghc/blob/ghc-7.10/compiler/main/DynFlags.hs#L1652-L1688

> I'm sure whoever suggested it as default and not extension will be happy
> with this too.

Just to clarify, GHC has a "default" mode when you don't specify
-XHaskell2010 nor -XHaskell98, quoting the user's guide[1]

,----
| By default, GHC mainly aims to behave (mostly) like a Haskell 2010
| compiler, although you can tell it to try to behave like a particular
| version of the language with the -XHaskell98 and -XHaskell2010
| flags. The known deviations from the standards are described
| below. Unless otherwise stated, the deviation applies in Haskell 98,
| Haskell 2010 and the default modes.
`----

But as soon as you have a cabal project, you get reminded to set the
`default-language` property, which most of the time is then set to
Haskell2010, which in turn means not having `-XNondecreasingIndentation`
enabled implicitly.


 [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs-and-infelicities.html#vs-Haskell-defn

From silvio.frischi at gmail.com  Tue Sep  8 21:17:17 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Tue, 8 Sep 2015 23:17:17 +0200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <87fv2oy6hs.fsf@gnu.org>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAF-LYK+vRfSSdHFXY7QxGjatdAbyiiCDOgbX0x+H2DoPJqVcVA@mail.gmail.com>
 <CAGW9QSyfgfFRMErkh+eqRUBiROzESpVtR=ddJHHe5nN6D7US_Q@mail.gmail.com>
 <55EEEE1F.6050909@plaimi.net> <55EEFBDB.30904@gmail.com>
 <55EF0CBA.3090600@ro-che.info> <55EF0F45.4050605@gmail.com>
 <87fv2oy6hs.fsf@gnu.org>
Message-ID: <55EF505D.20306@gmail.com>

You mean this?

languageExtensions Nothing
    -- Nothing => the default case
    = Opt_NondecreasingIndentation -- This has been on by default for
some time
    : delete Opt_DatatypeContexts  -- The Haskell' committee decided to
                                   -- remove datatype contexts from the
                                   -- language:
   --
http://www.haskell.org/pipermail/haskell-prime/2011-January/003335.html
      (languageExtensions (Just Haskell2010))

So default is
haskell2010+NondecreasingIndentation-DatatypeContexts

But the standard library can not be made to adhere to haskell98/2010.
I.e. Monad is now a subclass of Applicative.

Silvio

From gershomb at gmail.com  Tue Sep  8 21:58:57 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 8 Sep 2015 17:58:57 -0400
Subject: [Haskell-cafe] ANN: Creation of Haskell-Community list for
 Haskell.org Community Infrastructure Discussions
Message-ID: <CAM8RHpFA7M7=Ut9wijwo5wm9YPeZg_XsR7mxps8cB4HttAm0pg@mail.gmail.com>

Dear all,

The haskell.org committee [1] had a productive week during ICFP, and
at some point we'll try to write up some of the small things underway
and future plans -- many things are quite tentative at the moment.

However, one thing that became clear to us (well, thanks to the useful
prodding of SPJ) is that we have historically participated in
discussions in other venues (-cafe, reddit, etc) and then had our own
internal discussions (few, seldom, and largely organizational to be
honest) on the low-traffic committee [at] haskell.org mail alias.

But this leaves open people wondering what those discussions are. And
it also leaves open where the *designated place* to discuss
haskell.org community infrastructure is. The haskell-infrastructure
[2] list is very quiet and really about technical considerations.
Meanwhile, -cafe, reddit and soforth are about anything and
everything. So we created another list, which will be a place where we
seek to have our discussions related to plans for haskell.org
committee work, and where we invite everyone to join us.

This new list is the haskell-community list:
https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

The committee alias will still work, and is still the way to just
write directly to the members of the committee -- no list to join. But
if you wish to have a discussion about how we have things set up on
haskell community infrastructure, services provided, and that we might
wish to add, and how you can help (or even just what your thoughts are
on how things might be done), now there is a good place for that.

Hope to continue conversations with many of you there,
Gershom (for the haskell.org committee)

[1] https://wiki.haskell.org/Haskell.org_committee
[2] http://community.galois.com/mailman/listinfo/haskell-infrastructure

From ivan.miljenovic at gmail.com  Tue Sep  8 22:10:01 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Wed, 9 Sep 2015 08:10:01 +1000
Subject: [Haskell-cafe] emacs haskell-mode with cabal exec,
	test suite sections
In-Reply-To: <4D9DA0E3-B558-436D-A23F-460FAFCE3D94@lunaryorn.com>
References: <55ECA90C.1040104@panix.com>
 <CA+u6gbzUDXeVv42K8NUD7kg=jWtdfme6-5zueWR3qXo23i_3hA@mail.gmail.com>
 <4D9DA0E3-B558-436D-A23F-460FAFCE3D94@lunaryorn.com>
Message-ID: <CA+u6gbxcy8-Brg=_ee1=b4bvo_F1R5O1wdORMo53eKdDiVY8EQ@mail.gmail.com>

On 9 September 2015 at 03:27, Sebastian Wiesner <swiesner at lunaryorn.com> wrote:
>> Am 07.09.2015 um 00:01 schrieb Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com>:
>> Yeah, it claims to have sandbox support but for some reason I've never
>> managed to get it to stop complaining about not being able to find
>> modules installed in the sandbox.
>
> Flycheck does not support Cabal sandboxes out of the box.  You need to install and configure the addon package "flycheck-haskell".

I have that, but still keep getting "module not found" flycheck errors
now and then.



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From tkoster at gmail.com  Wed Sep  9 00:38:42 2015
From: tkoster at gmail.com (Thomas Koster)
Date: Wed, 9 Sep 2015 10:38:42 +1000
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAAr-h4v6kKXKAQG1YFM2TYEkO-wdPs3oPVa2csSoQNr-ZxW3Wg@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
 <CAAr-h4v6kKXKAQG1YFM2TYEkO-wdPs3oPVa2csSoQNr-ZxW3Wg@mail.gmail.com>
Message-ID: <CAG1wH7CvtYtn3K8kwh13AW5Um2tNFqw18h9GrVq9ZzYnFRBt1w@mail.gmail.com>

On 3 September 2015 at 09:23, Thomas Koster <tkoster at gmail.com> wrote:
> If you're going to fix all the warnings anyway, why not just use -Werror?

On 8 September 2015 at 22:41, Greg Horn <gregmainland at gmail.com> wrote:
> I'm not sure if this is ghci or emacs haskell-mode, but if I use -Werror in
> my cabal file then any warnings will cause ghci to fail loading, and I can't
> use helpful interactive features like `:t myFunction` or `print someValue`.

I didn't think about that.

I don't use Emacs so I'm just guessing here, but depending on how
haskell-mode works, you might be able to keep ghci happy by putting
":set -Wwarn" in your "~/.ghci" file, which should hopefully set
warnings to be warnings again for ghci only. However, this may mean
that ghci can compile a module where ghc refused and you're back where
you started.

--
Thomas Koster

From allbery.b at gmail.com  Wed Sep  9 00:40:43 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 8 Sep 2015 20:40:43 -0400
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAG1wH7CvtYtn3K8kwh13AW5Um2tNFqw18h9GrVq9ZzYnFRBt1w@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
 <CAAr-h4v6kKXKAQG1YFM2TYEkO-wdPs3oPVa2csSoQNr-ZxW3Wg@mail.gmail.com>
 <CAG1wH7CvtYtn3K8kwh13AW5Um2tNFqw18h9GrVq9ZzYnFRBt1w@mail.gmail.com>
Message-ID: <CAKFCL4VC+gU8H2zdPSOsTayemAu6BRCk0CvivOw79-3MkW2MXA@mail.gmail.com>

On Tue, Sep 8, 2015 at 8:38 PM, Thomas Koster <tkoster at gmail.com> wrote:

> I don't use Emacs so I'm just guessing here, but depending on how
> haskell-mode works, you might be able to keep ghci happy by putting
> ":set -Wwarn" in your "~/.ghci" file, which should hopefully set
> warnings to be warnings again for ghci only. However, this may mean
> that ghci can compile a module where ghc refused and you're back where
> you started.
>

:seti -Wwarn ?

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150908/a8360a77/attachment.html>

From tkoster at gmail.com  Wed Sep  9 01:08:39 2015
From: tkoster at gmail.com (Thomas Koster)
Date: Wed, 9 Sep 2015 11:08:39 +1000
Subject: [Haskell-cafe] Flag to recompile modules which had warnings
In-Reply-To: <CAKFCL4VC+gU8H2zdPSOsTayemAu6BRCk0CvivOw79-3MkW2MXA@mail.gmail.com>
References: <CAAbahfR_wBq6jKmTE+A+oq1XYPcu24g6OeA1k5NmxZNsXdzH_g@mail.gmail.com>
 <CAG1wH7BtaLu-VYpMp=AOfkU7tnQgHOUVMRY6C4A5dFfQLOxwKg@mail.gmail.com>
 <CAAr-h4v6kKXKAQG1YFM2TYEkO-wdPs3oPVa2csSoQNr-ZxW3Wg@mail.gmail.com>
 <CAG1wH7CvtYtn3K8kwh13AW5Um2tNFqw18h9GrVq9ZzYnFRBt1w@mail.gmail.com>
 <CAKFCL4VC+gU8H2zdPSOsTayemAu6BRCk0CvivOw79-3MkW2MXA@mail.gmail.com>
Message-ID: <CAG1wH7C4KHUurHqCm+k4NWKZZ_KuMvB8Pcfd20BWpwUKRXV-8A@mail.gmail.com>

On Tue, Sep 8, 2015 at 8:38 PM, Thomas Koster <tkoster at gmail.com> wrote:
> I don't use Emacs so I'm just guessing here, but depending on how
> haskell-mode works, you might be able to keep ghci happy by putting
> ":set -Wwarn" in your "~/.ghci" file, which should hopefully set
> warnings to be warnings again for ghci only. However, this may mean
> that ghci can compile a module where ghc refused and you're back where
> you started.

On 9 September 2015 at 10:40, Brandon Allbery <allbery.b at gmail.com> wrote:
> :seti -Wwarn ?

Yes, probably.

I was just guessing; I don't use ghci for this purpose myself, or
"-Werror" or Emacs :)

--
Thomas Koster

From saulzar at gmail.com  Wed Sep  9 02:30:55 2015
From: saulzar at gmail.com (Oliver Batchelor)
Date: Wed, 9 Sep 2015 14:30:55 +1200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <CAGzSZM7GqFNhwFaGmfGreZNbzeyWTi2s-YiJURuwRr34aMVisQ@mail.gmail.com>
Message-ID: <CAPGLJSnC5TMcE13RMMMBaSwpPs0D3Ed+Nvk0Ged8i39WC6DvZA@mail.gmail.com>

All of those examples look like good reasons to support the proposal to me.

I'm +1 on this for the simple reason that it takes an established practice
and removes syntactic noise. Is there an example where it actually adds
extra syntactic noise?

Cheers,
Oliver Batchelor

On Wed, Sep 9, 2015 at 12:36 AM, Alexey Vagarenko <vagarenko at gmail.com>
wrote:

> Consider this.
> If we didn't have $ operator in the first place, we'd use parentheses
> everywhere:
>
>     foo (bar (baz (qux (quux (do a <- b; return a)))))
> under your proposal it turns to:
>     foo (bar (baz (qux (quux do a <- b; return a))))
>
> another example:
>     foo (bar baz) (qux quux) (do a <- b; return a)
> turns to :
>     foo (bar baz) (qux quux) do a <- b; return a
>
> with lambdas:
>     foo (bar baz) (qux quux) (\x -> x)
> to:
>     foo (bar baz) (qux quux) \x -> x
>
> Can't you see your proposal makes things *less *consistent, *not more*?
> -1.
>
> 2015-09-07 0:03 GMT+06:00 Oliver Charles <ollie at ocharles.org.uk>:
>
>> I mean that people us $ for purely syntactical purposes. If an editor is
>> going to make refactorings and retain a certain sense of style, then the
>> tool needs to know that $ is sometimes to be used. The refactoring (or
>> otherwise) tool now has to be aware of the syntax of Haskell and special
>> symbols in the Prelude.
>>
>> On Sun, Sep 6, 2015 at 6:53 PM Matthew Pickering <
>> matthewtpickering at gmail.com> wrote:
>>
>>> >
>>> > I don't really like $ from an editor perspective though (tooling has to
>>> > become aware of a single function when performing refactorings), so
>>> anything
>>> > that helps reduce how prolific that operator is is a win in my book!
>>> >
>>>
>>> Can you please explain what you mean by this? Is there something more
>>> subtle that $ being a low fixity operator? Which specific problems
>>> does it cause tooling? Are you referring to the fact that there are
>>> problems because $ == id and makes tooling account for two cases when
>>> looking for refactorings? (I'm thinking of hlint here).
>>>
>>> (FWIW, haskell-src-exts tries to fiddle with the AST to account for
>>> fixity after parsing but the GHC parser does not, it happens during
>>> renaming. There is a pure version here[1] if anyone else is in need of
>>> this feature).
>>>
>>> Thanks, Matt
>>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150909/42c1987c/attachment.html>

From ok at cs.otago.ac.nz  Wed Sep  9 02:58:19 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Wed, 9 Sep 2015 14:58:19 +1200
Subject: [Haskell-cafe] GHC Extension Proposal: ArgumentBlock
In-Reply-To: <CAJWnFaNqWrR8DARau044YGv9FRpCQ-yE59hfcjJe8UnzVOcnfQ@mail.gmail.com>
References: <CAF-LYKJ3iaZG_4OZJVGzFyOqNXy=c1tprdHTgefBf8L2VCMZdw@mail.gmail.com>
 <61207021-fa55-4e3e-93c7-99fbd4663421@googlegroups.com>
 <CAGRp5R=Li7wPbtNXBoHtzUWb-dHn-SeYVfvVdP1bYt8kY9HR5w@mail.gmail.com>
 <CALuQ0m9iRDnZKsvnFeZ+F6RgNAfNAwE8UEyPZXRHrgitYkVbrw@mail.gmail.com>
 <CAGRp5RkWv8YeSepWumjd+gNU=H=6qLYhiM5h7WEm7rUywgxZEw@mail.gmail.com>
 <20150906181139.GL14413@weber>
 <CAKFe=dVj6=-ZkOT1WMb_W15kK+Wq++YdcN04K27qZENsh8eR_w@mail.gmail.com>
 <CAF-LYKJ3VVbam0uNiRTGL9m6-v0vFhKnhwkOZKatPZUrajb4ag@mail.gmail.com>
 <1441627827.1570.31.camel@joachim-breitner.de>
 <CAF-LYK+o=eeR__=NAQ50sQkZ+te543JzbABcey5gEANiVFoCHQ@mail.gmail.com>
 <CAGRp5RnJSmvG=XLdBuy1rpsQrwH0cwsRdQHg3524ZR+yVmgQ1A@mail.gmail.com>
 <CAF-LYKK4XYyEUhoad+LnxQE=etg=c-zmq0A6T0qXZ6mOnVfH8g@mail.gmail.com>
 <CALSygweD0aUF5msgJNhsXOkKUe46=u-KPZH9gw2xLMBtvqkNCA@mail.gmail.com>
 <mslmld$f6t$1@ger.gmane.org>
 <CAJWnFaNqWrR8DARau044YGv9FRpCQ-yE59hfcjJe8UnzVOcnfQ@mail.gmail.com>
Message-ID: <66C3C28E-D451-412E-A5C5-3DD1294DFB43@cs.otago.ac.nz>


On 8/09/2015, at 4:57 pm, Manuel G?mez <targen at gmail.com> wrote:
> 
> 
> We?re so used to understanding complex semantics and diverse,
> sometimes even obtuse styles of expression (pointfree, anyone?).

Correction.  We are used to TRYING to understand ...

Haskell long ago surpassed the opacity of much-maligned APL.

It's *already* bl---y hard to read some Haskell code and
removing signposts is *not* a good way to help the lost and
bewildered.

> Surely the mental effort of parsing a lambda or a do-block in a new,
> previously invalid syntax is a trivial matter for programmers
> accustomed to running type checking algorithms in our heads.

In the presence of type-level programming, my personal ability to
run a time-checking algorithm in my head turns out to be
embarrassingly limited.  In any case, surely you have heard the
proverb, "it's the last straw that breaks the camel's back"?

As for me, I make enough mistakes that I cherish a syntax which
rejects enough token sequences to catch many of my errors, while
not rejecting so many that constructing a valid program is a puzzle.
I'd be the last to say Haskell syntax is perfect, but it's d--ned good.



From davidfstr at gmail.com  Wed Sep  9 03:15:50 2015
From: davidfstr at gmail.com (David Foster)
Date: Tue, 08 Sep 2015 20:15:50 -0700
Subject: [Haskell-cafe] I wrote a type checker: ARF. Is it novel?
In-Reply-To: <55EED799.4040801@ifi.lmu.de>
References: <55ED02AC.7010109@gmail.com> <55EED799.4040801@ifi.lmu.de>
Message-ID: <55EFA466.90308@gmail.com>

 > On 07.09.2015 05:21, David Foster wrote:
 >> I've written a small untyped language calculus (ARF) [...]

On 9/8/15, 5:42 AM, Andreas Abel wrote:> Why not use one of the 40-year 
old type checking algorithms?
 >
 >    https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system

I was aware of the Hindley-Milner type system but judged it to not be an 
appropriate fit for my ultimate application, namely superimposing a 
static type system on top of Python's runtime type system in order to 
give it optional static typing.

The type system I have is a flow-based type system, similar to that used 
by David Pearce's Whiley language. I have extended his approach to 
interprocedural analysis, since I didn't want to require the programmer 
to insert any annotations in the original source code, which would be 
required by Pearce's original formulation.

 > What type do you infer for
 >
 >    def id(n):
 >        return n

If the program calls id() with (n = int) in at least one place, with (n 
= bool) in at least one place, and with no other argument types 
elsewhere, the type of id() will be inferred as:
* id(int) -> int
* id(bool) -> bool

You'll notice no parameterized type was introduced. The ARF type checker 
deals with simple non-parameterized types only.

From rustompmody at gmail.com  Wed Sep  9 04:13:07 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Wed, 9 Sep 2015 09:43:07 +0530
Subject: [Haskell-cafe] Stuck in proof of trivial compiler
Message-ID: <CAJ+TeoeP-8SLigwi3+jCbJ7HziKdgHD7OvPjN71GV009Qf0GoA@mail.gmail.com>

Trying to prove a trivial compiler with respect to a corresponding
interpreter
--------------- Code ------------------
+-* Expression tree
data Exp = Lf Int | Add Exp Exp | Mul Exp Exp

eval (Lf x) = x
eval (Add el er) = eval el + eval er
eval (Mul el er) = eval el * eval er


Simple stack machine instructions (LC is load constant)
data Instr = LC Int | AddI | MulI

compile (Lf x) = [LC x]
compile (Add el er) = compile el ++ compile er ++ [AddI]
compile (Mul el er) = compile el ++ compile er ++ [MulI]

mac [] stk = stk
mac (LC x : is) stk = mac is (x:stk)
mac (AddI : is) (r : l : stk) = mac is (l+r : stk)
mac (MulI : is) (r : l : stk) = mac is (l*r : stk)

------------ Proof Attempt -----------------------
Theorem mac(compile e).s = eval.e : s

Base case
mac(compile (Lf x)) s = eval (Lf x) : s

LHS =
mac (compile (Lf x)) s
mac [LC x] s
mac [] (x: s)
x: s

RHS =
eval (Lf x) : s
x: s

Induction Step:
Assumption l: mac (comp el).s = eval el : s
Assumption r: mac (comp er).s = eval er : s

LHS
= mac (Add el er) s
= mac (comp el ++ comp er ++ [AddI])


RHS
= eval (Add el er) : s
= (eval el + eval er) : s

Now What???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150909/807c29af/attachment.html>

From anselm.scholl at tu-harburg.de  Wed Sep  9 09:54:47 2015
From: anselm.scholl at tu-harburg.de (Jonas Scholl)
Date: Wed, 9 Sep 2015 11:54:47 +0200
Subject: [Haskell-cafe] Stuck in proof of trivial compiler
In-Reply-To: <CAJ+TeoeP-8SLigwi3+jCbJ7HziKdgHD7OvPjN71GV009Qf0GoA@mail.gmail.com>
References: <CAJ+TeoeP-8SLigwi3+jCbJ7HziKdgHD7OvPjN71GV009Qf0GoA@mail.gmail.com>
Message-ID: <55F001E7.9090102@tu-harburg.de>

How about trying to prove the following:

mac (compile e ++ x) s = mac x (eval e : s)

You can then just break down your term into pieces, build up the stack
and evaluate it in your prove.

On 09/09/2015 06:13 AM, Rustom Mody wrote:
> Trying to prove a trivial compiler with respect to a corresponding
> interpreter
> --------------- Code ------------------
> +-* Expression tree
> data Exp = Lf Int | Add Exp Exp | Mul Exp Exp
> 
> eval (Lf x) = x
> eval (Add el er) = eval el + eval er
> eval (Mul el er) = eval el * eval er
> 
> 
> Simple stack machine instructions (LC is load constant)
> data Instr = LC Int | AddI | MulI
> 
> compile (Lf x) = [LC x]
> compile (Add el er) = compile el ++ compile er ++ [AddI]
> compile (Mul el er) = compile el ++ compile er ++ [MulI]
> 
> mac [] stk = stk
> mac (LC x : is) stk = mac is (x:stk)
> mac (AddI : is) (r : l : stk) = mac is (l+r : stk)
> mac (MulI : is) (r : l : stk) = mac is (l*r : stk)
> 
> ------------ Proof Attempt -----------------------
> Theorem mac(compile e).s = eval.e : s
> 
> Base case
> mac(compile (Lf x)) s = eval (Lf x) : s
> 
> LHS =
> mac (compile (Lf x)) s
> mac [LC x] s
> mac [] (x: s)
> x: s
> 
> RHS =
> eval (Lf x) : s
> x: s
> 
> Induction Step:
> Assumption l: mac (comp el).s = eval el : s
> Assumption r: mac (comp er).s = eval er : s
> 
> LHS
> = mac (Add el er) s
> = mac (comp el ++ comp er ++ [AddI])
> 
> 
> RHS
> = eval (Add el er) : s
> = (eval el + eval er) : s
> 
> Now What???
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150909/783f17d9/attachment.sig>

From oleg at okmij.org  Wed Sep  9 10:32:49 2015
From: oleg at okmij.org (Oleg)
Date: Wed, 9 Sep 2015 19:32:49 +0900
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
Message-ID: <20150909103249.GA1738@Magus.sf-private>


Alexey Muranov wrote:
> My, maybe naive, impression is that there should always be one class per
> operation, as this is obviously the most flexible approach. Then maybe some
> classes can be grouped together by introducing other classes.

Truly what goes around comes around. The ``less ad hoc'' overloading
which we now associate with type classes was first proposed (and even
implemented!) by Stefan Kaes, a couple of years before the type
classes. Kaes so-called parametric overloading may be regarded as an
implementation of type classes with only one method.

        http://okmij.org/ftp/Computation/typeclass.html#Kaes

Incidentally, Kaes' system included not only `local instances' but
also `local classes'.

Likewise, 'Haskell with only one type class', 
        http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1

deals first with one-method classes. Type classes like Num are then
regarded as convenient collections, as bundles of previously defined
methods. Naturally, the same method, like (+), can be a part of
several bundles, not necessarily related otherwise. Incidentally, The
`Haskell with only one type class' required NO extensions, even back
in 2007, when it was first proposed.






From simonpj at microsoft.com  Wed Sep  9 11:42:03 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Sep 2015 11:42:03 +0000
Subject: [Haskell-cafe] ANN: Creation of Haskell-Community list for
 Haskell.org Community Infrastructure Discussions
In-Reply-To: <CAM8RHpFA7M7=Ut9wijwo5wm9YPeZg_XsR7mxps8cB4HttAm0pg@mail.gmail.com>
References: <CAM8RHpFA7M7=Ut9wijwo5wm9YPeZg_XsR7mxps8cB4HttAm0pg@mail.gmail.com>
Message-ID: <81dbf924153f45f7a68461c5135c19dc@DB4PR30MB030.064d.mgd.msft.net>

|  But this leaves open people wondering what those discussions are. And
|  it also leaves open where the *designated place* to discuss
|  haskell.org community infrastructure is. The haskell-infrastructure
|  [2] list is very quiet and really about technical considerations.
|  Meanwhile, -cafe, reddit and so forth are about anything and
|  everything. So we created another list, which will be a place where we
|  seek to have our discussions related to plans for haskell.org
|  committee work, and where we invite everyone to join us.

I think this is terrific, thanks Gershom.  Just to be clear, as I understand it, the intent is to broaden participation in the work of the haskell.org committee (which is our only single point of confluence covering the entire Haskell community) by making its discussions by-default open to everyone to join in.  Specifically:

* Anyone can write to the haskell-community list.

* Haskell.org committee members commit to reading the haskell-community
  list and writing to it.  That is, it's not a side-show.  The way to
  bring something to the attention of the committee (and the wider 
  community) is to write to the list.

* Discussion among haskell.org committee members takes place, by default,
  on the new, public, haskell-community mailing list.  (There is still a
  private list for members, but it is used only when there is a particular
  reason for not conducting a conversation in public; for example when
  debating nominations for new members of the committee.)

Perhaps it'd be worth adding a sub-section on https://wiki.haskell.org/Haskell.org_committee just to make these points?

Simon

|  -----Original Message-----
|  From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf
|  Of Gershom B
|  Sent: 08 September 2015 22:59
|  To: haskell-cafe; haskell at haskell.org; haskell-
|  infrastructure at community.galois.com; haskell-community at haskell.org
|  Subject: [Haskell-cafe] ANN: Creation of Haskell-Community list for
|  Haskell.org Community Infrastructure Discussions
|  
|  Dear all,
|  
|  The haskell.org committee [1] had a productive week during ICFP, and
|  at some point we'll try to write up some of the small things underway
|  and future plans -- many things are quite tentative at the moment.
|  
|  However, one thing that became clear to us (well, thanks to the useful
|  prodding of SPJ) is that we have historically participated in
|  discussions in other venues (-cafe, reddit, etc) and then had our own
|  internal discussions (few, seldom, and largely organizational to be
|  honest) on the low-traffic committee [at] haskell.org mail alias.
|  
|  But this leaves open people wondering what those discussions are. And
|  it also leaves open where the *designated place* to discuss
|  haskell.org community infrastructure is. The haskell-infrastructure
|  [2] list is very quiet and really about technical considerations.
|  Meanwhile, -cafe, reddit and soforth are about anything and
|  everything. So we created another list, which will be a place where we
|  seek to have our discussions related to plans for haskell.org
|  committee work, and where we invite everyone to join us.
|  
|  This new list is the haskell-community list:
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
|  
|  The committee alias will still work, and is still the way to just
|  write directly to the members of the committee -- no list to join. But
|  if you wish to have a discussion about how we have things set up on
|  haskell community infrastructure, services provided, and that we might
|  wish to add, and how you can help (or even just what your thoughts are
|  on how things might be done), now there is a good place for that.
|  
|  Hope to continue conversations with many of you there, Gershom (for
|  the haskell.org committee)
|  
|  [1] https://wiki.haskell.org/Haskell.org_committee
|  [2] http://community.galois.com/mailman/listinfo/haskell-
|  infrastructure
|  _______________________________________________
|  Haskell-Cafe mailing list
|  Haskell-Cafe at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From rustompmody at gmail.com  Wed Sep  9 13:25:10 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Wed, 9 Sep 2015 18:55:10 +0530
Subject: [Haskell-cafe] Stuck in proof of trivial compiler
In-Reply-To: <55F001E7.9090102@tu-harburg.de>
References: <CAJ+TeoeP-8SLigwi3+jCbJ7HziKdgHD7OvPjN71GV009Qf0GoA@mail.gmail.com>
 <55F001E7.9090102@tu-harburg.de>
Message-ID: <CAJ+TeodsRaBvC4LgZyoY9We3CY2PoKdGGQwxtFyqqfNfdfG+wA@mail.gmail.com>

On Wed, Sep 9, 2015 at 3:24 PM, Jonas Scholl <anselm.scholl at tu-harburg.de>
wrote:

> How about trying to prove the following:
>
> mac (compile e ++ x) s = mac x (eval e : s)
>
> You can then just break down your term into pieces, build up the stack
> and evaluate it in your prove.
>


Thanks Jonas, Janis
I knew I had to generalize it but not in '2 dimensions' -- x and s !
Seems obvious on further reflection
I wonder though what is the moral for formulating theorems of right
generality?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150909/82c97650/attachment.html>

From gershomb at gmail.com  Wed Sep  9 13:55:23 2015
From: gershomb at gmail.com (Gershom B)
Date: Wed, 9 Sep 2015 09:55:23 -0400
Subject: [Haskell-cafe] ANN: Creation of Haskell-Community list for
 Haskell.org Community Infrastructure Discussions
In-Reply-To: <81dbf924153f45f7a68461c5135c19dc@DB4PR30MB030.064d.mgd.msft.net>
References: <CAM8RHpFA7M7=Ut9wijwo5wm9YPeZg_XsR7mxps8cB4HttAm0pg@mail.gmail.com>
 <81dbf924153f45f7a68461c5135c19dc@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAM8RHpFLkU369yTPJLJo9rzkQJY5zAcLMWHZCW4=G8CyJ-+K0w@mail.gmail.com>

On Wed, Sep 9, 2015 at 7:42 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> * Anyone can write to the haskell-community list.
>
> * Haskell.org committee members commit to reading the haskell-community
>   list and writing to it.  That is, it's not a side-show.  The way to
>   bring something to the attention of the committee (and the wider
>   community) is to write to the list.
>
> * Discussion among haskell.org committee members takes place, by default,
>   on the new, public, haskell-community mailing list.  (There is still a
>   private list for members, but it is used only when there is a particular
>   reason for not conducting a conversation in public; for example when
>   debating nominations for new members of the committee.)
>
> Perhaps it'd be worth adding a sub-section on https://wiki.haskell.org/Haskell.org_committee just to make these points?

All correct bullet points, and the wiki has been updated to talk about
the list more specifically.

--gershom

From oleg.grenrus at iki.fi  Wed Sep  9 14:03:42 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Wed, 9 Sep 2015 17:03:42 +0300
Subject: [Haskell-cafe] Helsinki Haskell User Group metope,
	2015-09-24 @ 18:00 Gofore
Message-ID: <85C734C6-4B69-4292-8EAA-CADC1C36AEB9@iki.fi>

Dear all,

especially people not on the meetup.com.

After a summer break we'll resume Helsinki Haskell User Group meetups.
The first one will be on Thursday, September 24th at 18:00 at Gofore office.

We'll have three talks: about hpack & stack, purescript and history of functional programming.

If you are in the neighbourhood, join us. For details see:

http://www.meetup.com/Helsinki-Haskell-Users-Group/

Everybody is welcome!


Oleg Grenrus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150909/9da1607b/attachment.sig>

From philip.dexter at gmail.com  Wed Sep  9 14:29:08 2015
From: philip.dexter at gmail.com (Philip Dexter)
Date: Wed, 9 Sep 2015 10:29:08 -0400
Subject: [Haskell-cafe] Helsinki Haskell User Group metope,
 2015-09-24 @ 18:00 Gofore
In-Reply-To: <85C734C6-4B69-4292-8EAA-CADC1C36AEB9@iki.fi>
References: <85C734C6-4B69-4292-8EAA-CADC1C36AEB9@iki.fi>
Message-ID: <55F04234.5070407@gmail.com>

On 09/09/2015 10:03 AM, Oleg Grenrus wrote:
>
> After a summer break we'll resume Helsinki Haskell User Group meetups.
> The first one will be on Thursday, September 24th at 18:00 at Gofore office.

Bummer! I was in Helsinki this entire summer. I was hoping I could 
attend a meetup or two. I wasn't aware there was a summer break! Good to 
see that it's started again, though I'm gone for now.

From swiesner at lunaryorn.com  Wed Sep  9 17:16:40 2015
From: swiesner at lunaryorn.com (Sebastian Wiesner)
Date: Wed, 9 Sep 2015 19:16:40 +0200
Subject: [Haskell-cafe] emacs haskell-mode with cabal exec,
	test suite sections
In-Reply-To: <CA+u6gbxcy8-Brg=_ee1=b4bvo_F1R5O1wdORMo53eKdDiVY8EQ@mail.gmail.com>
References: <55ECA90C.1040104@panix.com>
 <CA+u6gbzUDXeVv42K8NUD7kg=jWtdfme6-5zueWR3qXo23i_3hA@mail.gmail.com>
 <4D9DA0E3-B558-436D-A23F-460FAFCE3D94@lunaryorn.com>
 <CA+u6gbxcy8-Brg=_ee1=b4bvo_F1R5O1wdORMo53eKdDiVY8EQ@mail.gmail.com>
Message-ID: <DFDDB874-933D-4F9C-A854-0DE1789D7EE5@lunaryorn.com>


> Am 09.09.2015 um 00:10 schrieb Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com>:
> 
> On 9 September 2015 at 03:27, Sebastian Wiesner <swiesner at lunaryorn.com> wrote:
>>> Am 07.09.2015 um 00:01 schrieb Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com>:
>>> Yeah, it claims to have sandbox support but for some reason I've never
>>> managed to get it to stop complaining about not being able to find
>>> modules installed in the sandbox.
>> 
>> Flycheck does not support Cabal sandboxes out of the box.  You need to install and configure the addon package "flycheck-haskell".
> 
> I have that, but still keep getting "module not found" flycheck errors
> now and then.

I might be able to help, but I'd need more information.  Would you mind to show your Flycheck-related Emacs configuration?

> -- 
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com


From defigueiredo at ucdavis.edu  Wed Sep  9 21:53:18 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Wed, 9 Sep 2015 15:53:18 -0600
Subject: [Haskell-cafe] lazily updating dependencies,
	git submodules and cabal
Message-ID: <55F0AA4E.7040609@ucdavis.edu>

Hello all,

I am facing a problem that I assume others have seen before, but am 
stumped for a solution. It's not about Haskell per se, but about how to 
organize my haskell code to play nicely with the build tools.

#The Setup

I am currently developing a bitcoin trading agent. I produce 2 
executables: the "Trader" and the "Tax" calculator. These 2 executables 
share a common dependency to talk to a SQLite3 database in their 
"Persistence" layer. (I actually have 3 levels of dependency, but we'll 
get to that later)

I spend most of my time working on the Trader and the Persistence layer. 
These are just different source code files: Trader.hs and 
Persistence.hs. The problem is that as I update the Persistence.hs file 
I break Tax.hs.

Because I am "lazy" and only really have to calculate taxes once I year. 
I do *not* want to have to continuously modify the Tax.hs file to keep 
up with the development in the Persistence layer. I just want it to use 
an old version, so that I only have to bring it up to speed later. In 
other words, I want to:

1. always be able to compile both executables,
2. delay updating an executable because of changes in a common 
dependency as much as possible.

I want to be lazy and delay updating my Tax.hs code to work with latest 
version of the Persistence layer a much as possible. At the same time, 
the Trader and Persistence layer are worked on simultaneously.

#My Current Solution

The immediate solution that comes to mind is to put these files in 3 
different packages. That way, I can use version 1.5 of the Persistence 
layer for the Tax calculator, but still develop version 2.0 at the same 
time as working on the Trader. I can use 'cabal sandbox add-source' to 
immediately get changes made to the Persistence layer as I develop the 
Trader. There is one minor problem with this approach: I have to 
manually track the version numbers. I need to put the proper version 
number in the "build-depends" section in the .cabal file. For example, 
for Tax.cabal I would have: "build-depends: persistence == 1.5".

There is a different approach that is completely orthogonal to using 
Cabal packages. I can put each of the 3 files (Trader.hs, Tax.hs and 
Persistence.hs) in 3 different repositories and use git submodules. The 
Persistence layer would be a submodule of both the Trader and the Tax 
repos. As each submodule just points to a specific commit in the 
Persistence repo, I don't have to manually track version numbers and the 
Trader and Tax calculator can point to different commits and use 
different versions of the Persistence layer.

The git solution is really convenient because when you clone a repo 
(with --recursive), it comes with the correct versions of the 
dependencies you need. This is what I did.

#The Problem

The problem I am facing is that I now have 3 (or more) levels and 
multiple dependencies. There are 2 changes to the original setup:
1. Persistence.hs now imports MarketModel.hs and that also changes 
pretty quickly as I develop the Trader.
2. The Trader now also depends on ProfitCalculator.hs that also imports 
MarketModel.hs

Using the 'cabal sandbox add-source' solution now requires that I 
"add-source" the MarketModel package too. Otherwise, any change I make 
to this package will not be tracked. In fact, I have to "add-source" two 
different versions of MarketModel (in general, there's an exponential 
blow up as the number of levels increases). The manual tracking of 
version numbers in the cabal file also becomes critical. If I forget to 
update a version number, the package will be reinstalled over an 
existing one that's being used. This quickly becomes a mess.

The git submodule solutions doesn't work either. Although GHC does the 
right thing and only complains about two modules with the same name if I 
use a symbol that is ambiguous. Cabal sets the paths for "import"ed 
modules in the "hs-source-dirs:" and that is global to the whole 
package. I can't say:

1. first, compile the Persistence.hs file by "import"ing files in the 
path /trader/persistence/marketmodel,
2. now, compile the ProfitCalculator.hs by "import"ing files in the path 
/trader/profitcalculator/marketmodel.

That path is the same for the whole project and I can't use different 
versions of MarketModel.hs

In short, it seems no solution works anymore. Is there a way to make 
this work? Is there another way for me to be lazy about updating my 
dependencies when building multiple targets? Any pointers on this would 
be much appreciated!


Thanks,


Dimitri


From dons00 at gmail.com  Thu Sep 10 09:51:03 2015
From: dons00 at gmail.com (Don Stewart)
Date: Thu, 10 Sep 2015 09:51:03 +0000
Subject: [Haskell-cafe] Senior Haskell developer roles at Standard Chartered,
	Singapore
Message-ID: <CAFd+Dr2fOkyOQt9zLJcQm6KiK9XyfsX2fFC2J_UgdaueNtVUTA@mail.gmail.com>

The Strats team at SCB has two more open roles for Haskell developers in
Singapore.

These are exciting "director level" development roles in a large team.
Location is Singapore.

Details here:

https://donsbot.wordpress.com/2015/09/10/senior-haskell-developer-roles-at-standard-chartered-singapore/

Please contact me for more details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150910/766a1476/attachment.html>

From star.tim.star at gmail.com  Thu Sep 10 12:50:12 2015
From: star.tim.star at gmail.com (timmy tofu)
Date: Thu, 10 Sep 2015 08:50:12 -0400
Subject: [Haskell-cafe] lazily updating dependencies,
	git submodules and cabal
Message-ID: <CADmHUV8MwhYMsmEAy5LNqz2UxnAwWZQDzaS++Uk+=3us-h5Fmw@mail.gmail.com>

>
> Using the 'cabal sandbox add-source' solution now requires that I
> "add-source" the MarketModel package too. Otherwise, any change I make
> to this package will not be tracked.
>

then?


> Cabal sets the paths for "import"ed
> modules in the "hs-source-dirs:" and that is global to the whole
> package.
>

 I can't tell if you do or do not want ProfitCalculator and Persistence to
track changes made in MarketModel.

If you do, and both should be in lock-step with it (unlike your situation
with Tax), then you don't have a problem.

If not, then the problem is Trader would depend on ProfitCalculator which
might depend on a different version of MarketModel than Persistence (upon
which Trader also depends). That is a classic dependency problem and not a
function of submodules or add-sourcing, per se. The Trader module seems to
be at the top of this heap - why would you want the Trader to (indirectly)
use one version of MarketModel through ProfitCalculator, and another
through Persistence?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150910/e8cf52c7/attachment.html>

From nicola.gigante at gmail.com  Thu Sep 10 13:49:26 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 10 Sep 2015 15:49:26 +0200
Subject: [Haskell-cafe] Best deployment method for Hakyll websites (with
	Stack)?
Message-ID: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>

Hello,

Note, this is not a Hakyll question, after all.

I?m trying to host a hakyll website on a CentOS 7 server.
I want to replicate the setup I had with the previous site, made
with Jekyll: at each push on the git repository (hosted on the same
server), the branch is recompiled and deployed to the web server.

I already have the git hooks in place etc? The problem is how to
manage the installation of ghc, hakyll, and their dependencies.

I really really wish to have a clean solution. I really like stack, but
its ?per-user? directories make me wonder. The site compilation has
to be performed by the git user account, which does not have an
home directory. Can I setup a stack installation of a set of packages
and then point stack to use that and only that? 

Also, how about the integration with docker? Is it really so painless as
it is advertised? If I?ve understood correctly, I could install the 
docker image with stackage packages already installed, and tell stack
to use that image with docker, having the site compilation sandboxed.
Is it feasible?

Thank you for any advice,
Nicola


From michael at snoyman.com  Thu Sep 10 14:46:23 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 10 Sep 2015 17:46:23 +0300
Subject: [Haskell-cafe] Best deployment method for Hakyll websites (with
	Stack)?
In-Reply-To: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>
References: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>
Message-ID: <CAKA2JgL1tgm=SEOOn8wX5sbhS+cUxfsAMOt4Nhfqk1Zn-2raPw@mail.gmail.com>

I'm not sure if it answers your question, but: stack's installation doesn't
have to be user-local, it just has to be somewhere that the user has write
access to. The default in $HOME/.stack, but this can be overridden by
setting the STACK_ROOT environment variable. So for example, this could
work:

sudo mkdir /opt/stack
sudo chown git /opt/stack
export STACK_ROOT=/opt/stack
stack build hakyll

Using Docker will mean that you get all of the Stackage packages available
without needing to compile them, and could be a great solution. Check out
the Wiki page for more information on getting started with it:

https://github.com/commercialhaskell/stack/wiki/Docker

On Thu, Sep 10, 2015 at 4:49 PM, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

> Hello,
>
> Note, this is not a Hakyll question, after all.
>
> I?m trying to host a hakyll website on a CentOS 7 server.
> I want to replicate the setup I had with the previous site, made
> with Jekyll: at each push on the git repository (hosted on the same
> server), the branch is recompiled and deployed to the web server.
>
> I already have the git hooks in place etc? The problem is how to
> manage the installation of ghc, hakyll, and their dependencies.
>
> I really really wish to have a clean solution. I really like stack, but
> its ?per-user? directories make me wonder. The site compilation has
> to be performed by the git user account, which does not have an
> home directory. Can I setup a stack installation of a set of packages
> and then point stack to use that and only that?
>
> Also, how about the integration with docker? Is it really so painless as
> it is advertised? If I?ve understood correctly, I could install the
> docker image with stackage packages already installed, and tell stack
> to use that image with docker, having the site compilation sandboxed.
> Is it feasible?
>
> Thank you for any advice,
> Nicola
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150910/b4420b1d/attachment.html>

From manny at fpcomplete.com  Thu Sep 10 15:34:28 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Thu, 10 Sep 2015 08:34:28 -0700
Subject: [Haskell-cafe] Best deployment method for Hakyll websites (with
	Stack)?
In-Reply-To: <CAKA2JgL1tgm=SEOOn8wX5sbhS+cUxfsAMOt4Nhfqk1Zn-2raPw@mail.gmail.com>
References: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>
 <CAKA2JgL1tgm=SEOOn8wX5sbhS+cUxfsAMOt4Nhfqk1Zn-2raPw@mail.gmail.com>
Message-ID: <CACGj5vLWU3LZvC3BMRB5dcrrKd95N1U_0aGqPy1nMn12vziO8A@mail.gmail.com>

Also, how about the integration with docker? Is it really so painless as
>> it is advertised? If I?ve understood correctly, I could install the
>> docker image with stackage packages already installed, and tell stack
>> to use that image with docker, having the site compilation sandboxed.
>> Is it feasible?
>>
> The compilation is sandboxed, but ~/.stack is still used for things like
default configuration and the build plan cache, and <project>/.stack-work
is still used for build artifacts. Otherwise, every build would have to
start completely from scratch (since each stack build creates a new
container).

If you need complete isolation from anything on the host OS, you?re better
off running stack from within a Docker container you create yourself
(using docker
run). You can still use the images we publish
<https://hub.docker.com/u/fpco/>, you just wouldn?t be using setting docker:
true in your stack.yaml.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150910/99cd150b/attachment.html>

From kyle.marek.spartz at gmail.com  Thu Sep 10 15:48:09 2015
From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz)
Date: Thu, 10 Sep 2015 10:48:09 -0500
Subject: [Haskell-cafe] Best deployment method for Hakyll websites (with
	Stack)?
In-Reply-To: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>
References: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>
Message-ID: <2fcp3sk2ry1dja.fsf@gmail.com>

Does the web server *need* to be able to compile the website? Building
and serving a static site are separate concerns.

I build my Hakyll sites locally (and just switched some of them to
stack), and deploy just the _site directory to a static content server.

I wrote my own tool to do this with Amazon S3, but you could probably
rsync or scp the files to a public directory on your CentOS web
server. That's what the Hakyll docs suggest:

http://jaspervdj.be/hakyll/reference/Hakyll-Core-Configuration.html

My site.hs:

https://github.com/zeckalpha/kyle.marek-spartz.org/blob/master/site.hs#L247

The tool I wrote:

http://www.celador.mn/widely/

A comparable service that hosts static content:

https://divshot.com/



Nicola Gigante writes:

> Hello,
>
> Note, this is not a Hakyll question, after all.
>
> I?m trying to host a hakyll website on a CentOS 7 server.
> I want to replicate the setup I had with the previous site, made
> with Jekyll: at each push on the git repository (hosted on the same
> server), the branch is recompiled and deployed to the web server.
>
> I already have the git hooks in place etc? The problem is how to
> manage the installation of ghc, hakyll, and their dependencies.
>
> I really really wish to have a clean solution. I really like stack, but
> its ?per-user? directories make me wonder. The site compilation has
> to be performed by the git user account, which does not have an
> home directory. Can I setup a stack installation of a set of packages
> and then point stack to use that and only that?
>
> Also, how about the integration with docker? Is it really so painless as
> it is advertised? If I?ve understood correctly, I could install the
> docker image with stackage packages already installed, and tell stack
> to use that image with docker, having the site compilation sandboxed.
> Is it feasible?
>
> Thank you for any advice,
> Nicola
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

--
Kyle Marek-Spartz

From kane at kane.cx  Thu Sep 10 17:54:52 2015
From: kane at kane.cx (David Kraeutmann)
Date: Thu, 10 Sep 2015 19:54:52 +0200
Subject: [Haskell-cafe] Best deployment method for Hakyll websites (with
 Stack)?
In-Reply-To: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>
References: <18E48930-0673-4965-94E0-5E891B4949BF@gmail.com>
Message-ID: <55F1C3EC.5020302@kane.cx>

The way I deploy my website (kane.cx) is exactly as you do with Jekyll.
I do own the server though, so I just installed ghc/hakyll. You can
always push as a user with a home directory and give it access to the
relevant htdocs directory (using ACLs if neccessary).

Docker sounds like a cleaner idea, but I haven't done anything with it
except set up some pre-packaged stuff.

On 9/10/2015 3:49 PM, Nicola Gigante wrote:
> Hello,
> 
> Note, this is not a Hakyll question, after all.
> 
> I?m trying to host a hakyll website on a CentOS 7 server.
> I want to replicate the setup I had with the previous site, made
> with Jekyll: at each push on the git repository (hosted on the same
> server), the branch is recompiled and deployed to the web server.
> 
> I already have the git hooks in place etc? The problem is how to
> manage the installation of ghc, hakyll, and their dependencies.
> 
> I really really wish to have a clean solution. I really like stack, but
> its ?per-user? directories make me wonder. The site compilation has
> to be performed by the git user account, which does not have an
> home directory. Can I setup a stack installation of a set of packages
> and then point stack to use that and only that? 
> 
> Also, how about the integration with docker? Is it really so painless as
> it is advertised? If I?ve understood correctly, I could install the 
> docker image with stackage packages already installed, and tell stack
> to use that image with docker, having the site compilation sandboxed.
> Is it feasible?
> 
> Thank you for any advice,
> Nicola
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150910/d07c02d9/attachment.bin>

From defigueiredo at ucdavis.edu  Thu Sep 10 18:26:55 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Thu, 10 Sep 2015 12:26:55 -0600
Subject: [Haskell-cafe] lazily updating dependencies,
 git submodules and cabal
In-Reply-To: <CADmHUV8MwhYMsmEAy5LNqz2UxnAwWZQDzaS++Uk+=3us-h5Fmw@mail.gmail.com>
References: <CADmHUV8MwhYMsmEAy5LNqz2UxnAwWZQDzaS++Uk+=3us-h5Fmw@mail.gmail.com>
Message-ID: <55F1CB6F.1000205@ucdavis.edu>

Yes, it's the classic diamond dependency graph.
   A
  / \
B  C
  \ /
   D

A = Trader, B = ProfitCalculator, C = Persistence, D = MarketModel.
It is not that I *want* Trader (A) to depend on two different versions 
of MarketModel (D), that is just a consequence. I don't have a choice.

What I want is for the ProfitCalculator (B) and Persistence (C) to 
always build. And if an update changes the MarketModel (D) from 
underneath them, they might break. So, I want them to each lock-in a 
specific version. In effect, I am forcing the graph above to turn into 
something like.
     A
    / \
   B  C
  /     \
D       D'

I may not write any code that uses the MarketModel (D) directly on the 
Trader (A).
I do understand that there are at least 1 point to keep in mind:
  types defined in D will be different from those in D' (typeclasses 
will be defined twice)

But the benefit of *not* having to always keep everything building on 
the latest version every time I update the MarketModel (D) is huge for me!


Cheers,


Dimitri



Em 10/09/15 06:50, timmy tofu escreveu:
>
>     Using the 'cabal sandbox add-source' solution now requires that I
>     "add-source" the MarketModel package too. Otherwise, any change I make
>     to this package will not be tracked.
>
>
> then?
>
>     Cabal sets the paths for "import"ed
>     modules in the "hs-source-dirs:" and that is global to the whole
>     package.
>
>
>  I can't tell if you do or do not want ProfitCalculator and 
> Persistence to track changes made in MarketModel.
>
> If you do, and both should be in lock-step with it (unlike your 
> situation with Tax), then you don't have a problem.
>
> If not, then the problem is Trader would depend on ProfitCalculator 
> which might depend on a different version of MarketModel than 
> Persistence (upon which Trader also depends). That is a classic 
> dependency problem and not a function of submodules or add-sourcing, 
> per se. The Trader module seems to be at the top of this heap - why 
> would you want the Trader to (indirectly) use one version of 
> MarketModel through ProfitCalculator, and another through Persistence?
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150910/8c022686/attachment.html>

From dct25-561bs at mythic-beasts.com  Thu Sep 10 19:00:55 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Thu, 10 Sep 2015 20:00:55 +0100
Subject: [Haskell-cafe] lazily updating dependencies,
	git submodules and cabal
In-Reply-To: <55F1CB6F.1000205@ucdavis.edu>
References: <CADmHUV8MwhYMsmEAy5LNqz2UxnAwWZQDzaS++Uk+=3us-h5Fmw@mail.gmail.com>
 <55F1CB6F.1000205@ucdavis.edu>
Message-ID: <CAErCyQ8hNoxb=NkJ7cHhkhrufUiHdaiHzys1Nfps3ct2mMDvLw@mail.gmail.com>

Hi,

I'd recommend investigating using stack rather than cabal directly for
this. Stack is good for a situation where you need to split things up into
more than one .cabal file, and should be able to handle handle the
dependencies between the modules without getting itself in a twist.

By way of a non-solution, I'd also strongly recommend (from experience) not
letting bitrot take hold over the course of the year and then putting all
the effort in at the end to clean it all up at the end. If you're
struggling to keep the Tax module in sync with the rest of the system, then
that often indicates your dependencies are not quite right. For instance,
it seems suspicious that tax calculations know anything about persistence.

Hope that helps,

David



On 10 September 2015 at 19:26, Dimitri DeFigueiredo <
defigueiredo at ucdavis.edu> wrote:

> Yes, it's the classic diamond dependency graph.
>   A
>  / \
> B  C
>  \ /
>   D
>
> A = Trader, B = ProfitCalculator, C = Persistence, D = MarketModel.
> It is not that I *want* Trader (A) to depend on two different versions of
> MarketModel (D), that is just a consequence. I don't have a choice.
>
> What I want is for the ProfitCalculator (B) and Persistence (C) to always
> build. And if an update changes the MarketModel (D) from underneath them,
> they might break. So, I want them to each lock-in a specific version. In
> effect, I am forcing the graph above to turn into something like.
>     A
>    / \
>   B  C
>  /     \
> D       D'
>
> I may not write any code that uses the MarketModel (D) directly on the
> Trader (A).
> I do understand that there are at least 1 point to keep in mind:
>  types defined in D will be different from those in D' (typeclasses will
> be defined twice)
>
> But the benefit of *not* having to always keep everything building on the
> latest version every time I update the MarketModel (D) is huge for me!
>
>
> Cheers,
>
>
> Dimitri
>
>
>
> Em 10/09/15 06:50, timmy tofu escreveu:
>
> Using the 'cabal sandbox add-source' solution now requires that I
>> "add-source" the MarketModel package too. Otherwise, any change I make
>> to this package will not be tracked.
>>
>
> then?
>
>
>> Cabal sets the paths for "import"ed
>> modules in the "hs-source-dirs:" and that is global to the whole
>> package.
>>
>
>  I can't tell if you do or do not want ProfitCalculator and Persistence to
> track changes made in MarketModel.
>
> If you do, and both should be in lock-step with it (unlike your situation
> with Tax), then you don't have a problem.
>
> If not, then the problem is Trader would depend on ProfitCalculator which
> might depend on a different version of MarketModel than Persistence (upon
> which Trader also depends). That is a classic dependency problem and not a
> function of submodules or add-sourcing, per se. The Trader module seems to
> be at the top of this heap - why would you want the Trader to (indirectly)
> use one version of MarketModel through ProfitCalculator, and another
> through Persistence?
>
>
>
> _______________________________________________
> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150910/7605694b/attachment.html>

From ab at fmap.me  Thu Sep 10 23:58:14 2015
From: ab at fmap.me (Nikolay Amiantov)
Date: Fri, 11 Sep 2015 02:58:14 +0300
Subject: [Haskell-cafe] Strange problem with inference
Message-ID: <55F21916.4010307@fmap.me>

Hi Cafe,

I've been playing around with lens and stumbled upon strange GHC
behaviour. Consider this source (using lens package and GHC 7.10.2):

{-# LANGUAGE TypeFamilies #-}

import Control.Lens

class Test a where
  type TestT a
  myiso :: Iso' a (TestT a)

test1 :: Test a => a -> TestT a
test1 = view myiso

test2 :: Test a => TestT a -> a
test2 = view (from myiso)

GHC would emit this error:

/tmp/test.hs:13:9:
    Could not deduce (Control.Monad.Reader.Class.MonadReader
                        (TestT a) ((->) (TestT a)))
      arising from a use of ?view?
    from the context (Test a)
      bound by the type signature for test2 :: Test a => TestT a -> a
      at /tmp/test.hs:12:10-31
    In the expression: view (from myiso)
    In an equation for ?test2?: test2 = view (from myiso)
Failed, modules loaded: none.

However, `MonadReader r ((->) r)` is defined for any and all `r`!
Furthermore, `test1` has no problem with this and `view` there uses this
instance too. The only difference that I see is the presence of a type
family:

* `test1` needs `MonadReader a ((->) a)`
* `test2` needs `MonadReader (TestT a) ((->) (TestT a))`

, but I don't understand how can this result in a different behavior.
Notice that this likely may be reproduced somehow without lens -- I've
spent some time trying to minify this example further but alas to no avail.

Thanks in advance!

-- 
Nikolay.

From sumit.sahrawat.apm13 at iitbhu.ac.in  Fri Sep 11 02:17:24 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Fri, 11 Sep 2015 07:47:24 +0530
Subject: [Haskell-cafe] Strange problem with inference
In-Reply-To: <55F21916.4010307@fmap.me>
References: <55F21916.4010307@fmap.me>
Message-ID: <CAJbEW8OyCZ0ze-+4F8jkWW0UT2M208qcEAyKWMU7xo+Sid0wYw@mail.gmail.com>

One possible fix (tested on GHC-7.10.1 with lens-4.12.3):

test2 :: (Test a, t ~ TestT a) => t -> a
test2 = view (from myiso)

This might have something to do with type families not being injective, but
I'm not completely sure.

I also agree that it might be possible to trigger this without lens, will
try to find an example and post if I succeed.

On 11 September 2015 at 05:28, Nikolay Amiantov <ab at fmap.me> wrote:

> Hi Cafe,
>
> I've been playing around with lens and stumbled upon strange GHC
> behaviour. Consider this source (using lens package and GHC 7.10.2):
>
> {-# LANGUAGE TypeFamilies #-}
>
> import Control.Lens
>
> class Test a where
>   type TestT a
>   myiso :: Iso' a (TestT a)
>
> test1 :: Test a => a -> TestT a
> test1 = view myiso
>
> test2 :: Test a => TestT a -> a
> test2 = view (from myiso)
>
> GHC would emit this error:
>
> /tmp/test.hs:13:9:
>     Could not deduce (Control.Monad.Reader.Class.MonadReader
>                         (TestT a) ((->) (TestT a)))
>       arising from a use of ?view?
>     from the context (Test a)
>       bound by the type signature for test2 :: Test a => TestT a -> a
>       at /tmp/test.hs:12:10-31
>     In the expression: view (from myiso)
>     In an equation for ?test2?: test2 = view (from myiso)
> Failed, modules loaded: none.
>
> However, `MonadReader r ((->) r)` is defined for any and all `r`!
> Furthermore, `test1` has no problem with this and `view` there uses this
> instance too. The only difference that I see is the presence of a type
> family:
>
> * `test1` needs `MonadReader a ((->) a)`
> * `test2` needs `MonadReader (TestT a) ((->) (TestT a))`
>
> , but I don't understand how can this result in a different behavior.
> Notice that this likely may be reproduced somehow without lens -- I've
> spent some time trying to minify this example further but alas to no avail.
>
> Thanks in advance!
>
> --
> Nikolay.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150911/c6b1a429/attachment.html>

From ab at fmap.me  Fri Sep 11 09:32:22 2015
From: ab at fmap.me (Nikolay Amiantov)
Date: Fri, 11 Sep 2015 12:32:22 +0300
Subject: [Haskell-cafe] Strange problem with inference
In-Reply-To: <CAJbEW8OyCZ0ze-+4F8jkWW0UT2M208qcEAyKWMU7xo+Sid0wYw@mail.gmail.com>
References: <55F21916.4010307@fmap.me>
 <CAJbEW8OyCZ0ze-+4F8jkWW0UT2M208qcEAyKWMU7xo+Sid0wYw@mail.gmail.com>
Message-ID: <55F29FA6.8090906@fmap.me>

An interesting fix, indeed! I think this might be a bug in GHC -- these
should (if I understand correctly) be equivalent signatures. I'll try to
find a simpler example too before reporting this, it might shed some
light on things (maybe even enough to show this isn't a bug at all ^_^).

On 09/11/2015 05:17 AM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote:
> One possible fix (tested on GHC-7.10.1 with lens-4.12.3):
> 
> test2 :: (Test a, t ~ TestT a) => t -> a
> test2 = view (from myiso)
> 
> This might have something to do with type families not being injective,
> but I'm not completely sure.
> 
> I also agree that it might be possible to trigger this without lens,
> will try to find an example and post if I succeed.
-- 
Nikolay.

From vogt.adam at gmail.com  Fri Sep 11 20:30:42 2015
From: vogt.adam at gmail.com (adam vogt)
Date: Fri, 11 Sep 2015 16:30:42 -0400
Subject: [Haskell-cafe] Strange problem with inference
In-Reply-To: <CAJbEW8OyCZ0ze-+4F8jkWW0UT2M208qcEAyKWMU7xo+Sid0wYw@mail.gmail.com>
References: <55F21916.4010307@fmap.me>
 <CAJbEW8OyCZ0ze-+4F8jkWW0UT2M208qcEAyKWMU7xo+Sid0wYw@mail.gmail.com>
Message-ID: <CAHfjoW=6SvACx3pXgfkP=Y8-T8+d40c+1JJ7n1_BunrAkEqDAw@mail.gmail.com>

I've tested with ghc-7.8.4, and the test1/test2 definitions are accepted if
you use -XNoMonomorphismRestriction.

For test2 to work without annotating a result type, you could use a
superclass constraint to show that the type family has an inverse. In
ghc-7.10 it doesn't work (see https://ghc.haskell.org/trac/ghc/ticket/10009)

https://gist.github.com/aavogt/7a10024f0199dc2e8478 shows both features.

On Thu, Sep 10, 2015 at 10:17 PM, Sumit Sahrawat, Maths & Computing, IIT
(BHU) <sumit.sahrawat.apm13 at iitbhu.ac.in> wrote:

> One possible fix (tested on GHC-7.10.1 with lens-4.12.3):
>
> test2 :: (Test a, t ~ TestT a) => t -> a
> test2 = view (from myiso)
>
> This might have something to do with type families not being injective,
> but I'm not completely sure.
>
> I also agree that it might be possible to trigger this without lens, will
> try to find an example and post if I succeed.
>
> On 11 September 2015 at 05:28, Nikolay Amiantov <ab at fmap.me> wrote:
>
>> Hi Cafe,
>>
>> I've been playing around with lens and stumbled upon strange GHC
>> behaviour. Consider this source (using lens package and GHC 7.10.2):
>>
>> {-# LANGUAGE TypeFamilies #-}
>>
>> import Control.Lens
>>
>> class Test a where
>>   type TestT a
>>   myiso :: Iso' a (TestT a)
>>
>> test1 :: Test a => a -> TestT a
>> test1 = view myiso
>>
>> test2 :: Test a => TestT a -> a
>> test2 = view (from myiso)
>>
>> GHC would emit this error:
>>
>> /tmp/test.hs:13:9:
>>     Could not deduce (Control.Monad.Reader.Class.MonadReader
>>                         (TestT a) ((->) (TestT a)))
>>       arising from a use of ?view?
>>     from the context (Test a)
>>       bound by the type signature for test2 :: Test a => TestT a -> a
>>       at /tmp/test.hs:12:10-31
>>     In the expression: view (from myiso)
>>     In an equation for ?test2?: test2 = view (from myiso)
>> Failed, modules loaded: none.
>>
>> However, `MonadReader r ((->) r)` is defined for any and all `r`!
>> Furthermore, `test1` has no problem with this and `view` there uses this
>> instance too. The only difference that I see is the presence of a type
>> family:
>>
>> * `test1` needs `MonadReader a ((->) a)`
>> * `test2` needs `MonadReader (TestT a) ((->) (TestT a))`
>>
>> , but I don't understand how can this result in a different behavior.
>> Notice that this likely may be reproduced somehow without lens -- I've
>> spent some time trying to minify this example further but alas to no
>> avail.
>>
>> Thanks in advance!
>>
>> --
>> Nikolay.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Regards
>
> Sumit Sahrawat
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150911/a1082c91/attachment.html>

From winterkoninkje at gmail.com  Sat Sep 12 02:05:56 2015
From: winterkoninkje at gmail.com (wren romano)
Date: Fri, 11 Sep 2015 22:05:56 -0400
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
Message-ID: <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>

On Mon, Sep 7, 2015 at 10:08 AM, DreamApart AtHaskells
<rnmss.hs at gmail.com> wrote:
> A feasible design is: [...]

I'm all for redesigning the numeric hierarchy, but I must (once again)
raise my standard complaint against this sort of work, namely: there
must be a class for semirings.

Abelian groups are nice and all, but they are not the principle origin
for rings. There are far more objects which have
addition/multiplication without subtraction than there are objects
with addition/subtraction without multiplication. Everyone I've seen
suggest redesigning Num keeps overlooking this fact, since they're all
so hung up on module/vector spaces.

-- 
Live well,
~wren

From davidleothomas at gmail.com  Sat Sep 12 06:50:51 2015
From: davidleothomas at gmail.com (David Thomas)
Date: Fri, 11 Sep 2015 23:50:51 -0700
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
Message-ID: <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>

I think we definitely want to keep subtraction separate, and maybe
even allow for a subtraction operation that returns a different
type...

On Fri, Sep 11, 2015 at 7:05 PM, wren romano <winterkoninkje at gmail.com> wrote:
> On Mon, Sep 7, 2015 at 10:08 AM, DreamApart AtHaskells
> <rnmss.hs at gmail.com> wrote:
>> A feasible design is: [...]
>
> I'm all for redesigning the numeric hierarchy, but I must (once again)
> raise my standard complaint against this sort of work, namely: there
> must be a class for semirings.
>
> Abelian groups are nice and all, but they are not the principle origin
> for rings. There are far more objects which have
> addition/multiplication without subtraction than there are objects
> with addition/subtraction without multiplication. Everyone I've seen
> suggest redesigning Num keeps overlooking this fact, since they're all
> so hung up on module/vector spaces.
>
> --
> Live well,
> ~wren
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From alexey.muranov at gmail.com  Sat Sep 12 08:15:48 2015
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Sat, 12 Sep 2015 01:15:48 -0700 (PDT)
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
Message-ID: <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>

My 2 cents: the difference of two points in an affine space is a vector, 
the sum of a point of an affine space and a vector is another point.

On Saturday, September 12, 2015 at 8:50:58 AM UTC+2, David Thomas wrote:
>
> I think we definitely want to keep subtraction separate, and maybe 
> even allow for a subtraction operation that returns a different 
> type... 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150912/93f70f24/attachment.html>

From strake888 at gmail.com  Sat Sep 12 08:51:53 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sat, 12 Sep 2015 00:51:53 -0800
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
 <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
Message-ID: <CAL3m8eA-m5D0xQSk94mCMH7W4DTdb3BsETZKN3ZEzbt4B=MVkg@mail.gmail.com>

On 11/09/2015, David Thomas <davidleothomas at gmail.com> wrote:
> a subtraction operation that returns a different type

On 12/09/2015, Alexey Muranov <alexey.muranov at gmail.com> wrote:
> My 2 cents: the difference of two points in an affine space is a vector,
> the sum of a point of an affine space and a vector is another point.

This would mean multi-parametre type classes or type families, so we'd
need to canonicalize them first, which seems unlikely in near future
at least.

From alexey.muranov at gmail.com  Sat Sep 12 09:11:26 2015
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Sat, 12 Sep 2015 02:11:26 -0700 (PDT)
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CAL3m8eA-m5D0xQSk94mCMH7W4DTdb3BsETZKN3ZEzbt4B=MVkg@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
 <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
 <CAL3m8eA-m5D0xQSk94mCMH7W4DTdb3BsETZKN3ZEzbt4B=MVkg@mail.gmail.com>
Message-ID: <a053118f-741d-486b-b8a5-439e436f2b15@googlegroups.com>

Maybe it is unreasonable to look for maximal generality in use of each 
operator.

A common use of "+" is for the operation of an abelian semigroup or monoid 
(any semigroup can be converted into a monoid anyway).

Alexey.

P.S. I was tempted to suggest "++" for cancellative monoids and "**" for 
arbitrary monoids, but "++" on lists is not quite cancellative if one of 
the lists is infinite.


On Saturday, September 12, 2015 at 10:52:01 AM UTC+2, M Farkas-Dyck wrote:
>
> On 11/09/2015, David Thomas <davidle... at gmail.com <javascript:>> wrote: 
> > a subtraction operation that returns a different type 
>
> On 12/09/2015, Alexey Muranov <alexey.... at gmail.com <javascript:>> wrote: 
> > My 2 cents: the difference of two points in an affine space is a vector, 
> > the sum of a point of an affine space and a vector is another point. 
>
> This would mean multi-parametre type classes or type families, so we'd 
> need to canonicalize them first, which seems unlikely in near future 
> at least. 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150912/ba54b74e/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Sat Sep 12 09:12:27 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Sat, 12 Sep 2015 11:12:27 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
 <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
Message-ID: <55F3EC7B.70103@unicaen.fr>

Le 12/09/2015 10:15, Alexey Muranov a ?crit :
> the difference of two points in an affine space is a vector, the sum 
> of a point of an affine space and a vector is another point.

We can give several similar examples, but it might not be so useful for 
the implementation of whatever. In the affine space we can interpolate 
between points: p0 + 1/2*(p1-p0) is the middle point. Writing it just as
1/2*(p0+p1) might be considered as an abomination, since you should not 
add points... Who should allow the first and forbid the second?

Programming languages is not mathematics. Types are not mathematical 
domains. Classes are not categories... Whatever we/you propose, there 
will be many unhappy people around. Math is full of subsumptions, whose 
automatic implementation might be difficult, inefficient or ambiguous.

If you have an additive group, you have automatically a module over 
integers. Sorry, *positive* integers. So, we might second David Thomas, 
we should have Rigs (semi-rings). But why a *class*?? And, if you define 
such object by hand, you may be accused of introducing redundancies, 
that it should be inferred...
And whatever people say, e.g., Wren Romano:

> There are far more objects which have
> addition/multiplication without subtraction than there are objects
> with addition/subtraction without multiplication.
... several simple-minded people (myself included)  will find not so 
useful and/or clumsy the introduction of specific structures just to 
forbid the subtraction. Nobody will fight against these purists, it is 
simply a difficult issue.

All this is a can of worms, and physicists live with it already for 
centuries
[Time : add please today to yesterday... Subtract works.  They were 
happy, because there were no computer formalisators around, who could 
bother them...].

Please read the *easy* article of John Baez (2009) : 
http://math.ucr.edu/home/baez/torsors.html
And then look upon torsors in general, and recognize that is is simply 
horrible.
==

All the best.

Jerzy Karczmarczuk
/Caen, France/


From alexey.muranov at gmail.com  Sat Sep 12 09:27:40 2015
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Sat, 12 Sep 2015 11:27:40 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <55F3EC7B.70103@unicaen.fr>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
 <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
 <55F3EC7B.70103@unicaen.fr>
Message-ID: <0FFE40C9-7299-47E1-84BD-608E7798653E@gmail.com>


On 12 sept. 2015, at 11:12, Jerzy Karczmarczuk <jerzy.karczmarczuk at unicaen.fr> wrote:

> Le 12/09/2015 10:15, Alexey Muranov a ?crit :
>> the difference of two points in an affine space is a vector, the sum of a point of an affine space and a vector is another point.
> 
> We can give several similar examples, but it might not be so useful for the implementation of whatever. In the affine space we can interpolate between points: p0 + 1/2*(p1-p0) is the middle point. Writing it just as
> 1/2*(p0+p1) might be considered as an abomination, since you should not add points... Who should allow the first and forbid the second?

I agree, it gets complicated. A more general type of "weighted sums of points" would probably be needed, but impractical...

> If you have an additive group, you have automatically a module over integers. Sorry, *positive* integers.

Well, over all integers as well.

> Please read the *easy* article of John Baez (2009) : http://math.ucr.edu/home/baez/torsors.html
> And then look upon torsors in general, and recognize that is is simply horrible.

I didn't get this (i do not know much about torsors).

Alexey.

From olf at aatal-apotheke.de  Sat Sep 12 12:39:53 2015
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 12 Sep 2015 14:39:53 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type 	class
Message-ID: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>

I sencond the statement that semirings might be a useful typeclass to have. Another example: Non-negative reals with infinity, the values that a measure can take. Nevertheless the biggest issue is what _symbol_ to use for the operations. We know that a ring is a semigroup in two ways, and no matter what semigroup structure we think the ring to "originate" from, we're going to annoy the other half of users who thought it the other way around. Some semigroups are thought of as (+), others as (*). Picking one of these symbols for all semigroups will be counter-intuitive for some structures. 
As to affine structures, Martin Escardo and Alex Simpson have a paper showing that the unit interval is the free cancellative midpoint algebra over two generators. They have Haskell code for this [1]. 
And yes, a typeclass is not a mathematical category, but Haskell is a language that lets you formalise quite a bit of category theory, and this is a cool thing to have. You can read a paper based on category theory and obtain executable code with very little effort. There are now entire Ph.D. theses written in Agda. 

To me it seems that the solution to the Num typeclass problem would be to have sub-typeclass statements that let you introduce aliases for the operations, as so: 

class Semigroup a where
  (<>) :: a -> a -> a

class Group a where
  (*) :: a -> a -> a
  unit :: a
  inverse :: a -> a

superclass Semigroup Group where
  (<>) = (*)

But wait, we do have a mechanism for aliases: It's called newtype! Conclusion: If you want to express that any Num instance is a Group, do so with a newtype. Data.Monoid is a good example for this. 

-- Olaf

[1] http://www.cs.bham.ac.uk/~mhe/.talks/map2011/martin_map.pdf

From jerzy.karczmarczuk at unicaen.fr  Sat Sep 12 15:59:14 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Sat, 12 Sep 2015 17:59:14 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>
References: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>
Message-ID: <55F44BD2.1080307@unicaen.fr>


Le 12/09/2015 14:39, Olaf Klinke a ?crit :
> semirings might be a useful typeclass to have. Another example: Non-negative reals with infinity, the values that a measure can take.
Could you mention, please, a system whose measures are for sure positive 
reals, infinity included?
Perhaps your definition of "measure"should be precised...
Thanks.

Jerzy Karczmarczuk


From diaz.carrete at gmail.com  Sat Sep 12 16:46:03 2015
From: diaz.carrete at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz?=)
Date: Sat, 12 Sep 2015 09:46:03 -0700 (PDT)
Subject: [Haskell-cafe] haskell est il compatible avec mon projet
	graphique ?
In-Reply-To: <5f14856f-ff7f-4c33-b4b6-298937779046@googlegroups.com>
References: <5f14856f-ff7f-4c33-b4b6-298937779046@googlegroups.com>
Message-ID: <5247aa09-f9e0-4484-8b9d-1558562d7aca@googlegroups.com>

Pardonnez mon mauvais fran?ais.

Il existe des liaisons pour SDL2: http://hackage.haskell.org/package/sdl2

Aussi jeter un oeil ? "diagrams" 
 http://projects.haskell.org/diagrams/gallery.html 

On Saturday, September 12, 2015 at 6:17:04 AM UTC+2, Vincent Douce LR wrote:
>
> salut ? tous
> je dois r?aliser des cr?ations graphiques, avec deux destinations : des 
> animations sur l'?cran, et des images fixes destin?es ? ?tre publi?es sur 
> papier
> ces cr?ations reposent sur des algorithmes de mon cr?
> je souhaite me cr?er une biblioth?que de s?quences de code que je pourrai 
> ?toffer au fur et ? mesure et utiliser dans mes programmes
> je cherche quel langage adopter, et quel pendant graphique lui adjoindre
> j'envisage des pistes comme C+sdl ou python +?
> utiliser haskell serait un d?fi parce que c'est moins intuitif pour moi un 
> langage fonctionnel et aussi tout simplemetn parce que je n'y connais rien 
> en haskell, je sais juste un peu de Scheme
> mais peut ?tre qu'il y a dans l'univers haskell un moyen de g?n?rer des 
> graphiques de qualit? ? je susi ouvert
> qu'en pensez-vous ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150912/b522d6b7/attachment.html>

From carter.schonwald at gmail.com  Sat Sep 12 17:45:20 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 12 Sep 2015 13:45:20 -0400
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <55F44BD2.1080307@unicaen.fr>
References: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>
 <55F44BD2.1080307@unicaen.fr>
Message-ID: <CAHYVw0w3M7gtuC7YuEjRXO76gBds0vZ6CjJ9Qk7pjFtgbHY=yQ@mail.gmail.com>

I have this deep worry that any changes to num hierarchy that aren't first
demonstrated in userland.  This is perhaps me being a little bit of a
curmudgeon.  I just feel like it's a complicated topic that needs lots of
concrete example experiments to really pin down what's what.

Additionally, most of the proposals over time  seem to a) have some latent
form of abstraction blindness with respect to some notion of
parametrization that we can't even name / describe with Haskell
(Which is actually something I'm starting to think about, though often
passing around records of functions is good enough, ignoring the question
of performance implications)

B) there's usually a whole bunch of different computable realizations of
how to Manipulate a given mathematical object, which when exposed as apis
hsve wildly different performance characteristics and ease of use

An example of (a) is we can't really talk about a family of type classes
which are parametrized over the names of their methods. (We spend so much
time jumping through that hoop when relating ring and group structures!

An example of the latter (b) would be any model of integration / measurable
functions. We as humans are still learning on that front. Witness the huge
amount of work (still nascent) in probabilistic programming, which is
essentially about "what is an efficient and usable way to talk about
integrating over interesting things"

On Saturday, September 12, 2015, Jerzy Karczmarczuk <
jerzy.karczmarczuk at unicaen.fr> wrote:

>
> Le 12/09/2015 14:39, Olaf Klinke a ?crit :
>
>> semirings might be a useful typeclass to have. Another example:
>> Non-negative reals with infinity, the values that a measure can take.
>>
> Could you mention, please, a system whose measures are for sure positive
> reals, infinity included?
> Perhaps your definition of "measure"should be precised...
> Thanks.
>
> Jerzy Karczmarczuk
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150912/1883cb81/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Sat Sep 12 19:15:41 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Sat, 12 Sep 2015 21:15:41 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CAML5wvsJFCYS1j4iivm7qyAFjeQmBW6Zx-qNXOrSGkKNaHNZ9g@mail.gmail.com>
References: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>
 <55F44BD2.1080307@unicaen.fr>
 <CAML5wvsJFCYS1j4iivm7qyAFjeQmBW6Zx-qNXOrSGkKNaHNZ9g@mail.gmail.com>
Message-ID: <55F479DD.8010308@unicaen.fr>

Dominique Devriese comments my remark :
> Could you mention, please, a system whose measures are for sure positive
> reals, infinity included?
here:
> I think he's talking about the mathematical notion of measure:
> https://en.wikipedia.org/wiki/Measure_(mathematics)
Gosh, I should have read Olaf Klinke somewhat slower...
But I was a physicist too long. Sorry!

On the other hand, I would like to see where, in what kind of 
computations, the Rig type class would be useful (and how to squeeze 
infinity into it). I spent some time doing some computations using 
probabilistic measures and very standard programming standards, and I am 
conservatist. Of course, as Macchiavelli said in "Prince" (more or 
less):  "the innovator makes enemies of all those who have done well 
under the old conditions".
I am doubtful whether I "did well", but I wait for the innovators to 
show me their "new conditions". A good example, where a new Prelude with 
Rigs, Rngs, etc., permit to solve better some concrete, useful 
computational problems.

Thanks in advance.

Jerzy Karczmarczuk


From amindfv at gmail.com  Sat Sep 12 19:24:59 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sat, 12 Sep 2015 15:24:59 -0400
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CAL3m8eA-m5D0xQSk94mCMH7W4DTdb3BsETZKN3ZEzbt4B=MVkg@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
 <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
 <CAL3m8eA-m5D0xQSk94mCMH7W4DTdb3BsETZKN3ZEzbt4B=MVkg@mail.gmail.com>
Message-ID: <0992D1FA-AE8B-47BF-8D26-DCFD8D80013C@gmail.com>

In case you haven't seen it, "vector-space" provides a good representation of affine spaces, additive groups, etc


El Sep 12, 2015, a las 4:51, M Farkas-Dyck <strake888 at gmail.com> escribi?:

> On 11/09/2015, David Thomas <davidleothomas at gmail.com> wrote:
>> a subtraction operation that returns a different type
> 
> On 12/09/2015, Alexey Muranov <alexey.muranov at gmail.com> wrote:
>> My 2 cents: the difference of two points in an affine space is a vector,
>> the sum of a point of an affine space and a vector is another point.
> 
> This would mean multi-parametre type classes or type families, so we'd
> need to canonicalize them first, which seems unlikely in near future
> at least.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From kane at kane.cx  Sat Sep 12 20:31:10 2015
From: kane at kane.cx (David Kraeutmann)
Date: Sat, 12 Sep 2015 22:31:10 +0200
Subject: [Haskell-cafe] Strange problem with inference
In-Reply-To: <55F29FA6.8090906@fmap.me>
References: <55F21916.4010307@fmap.me>
 <CAJbEW8OyCZ0ze-+4F8jkWW0UT2M208qcEAyKWMU7xo+Sid0wYw@mail.gmail.com>
 <55F29FA6.8090906@fmap.me>
Message-ID: <CAJ8B99zoA=pLKhwzhT5nLYRhXgnXwwWhwjZ1fp9hoi5Ehk+akA@mail.gmail.com>

~ isn't equivalent. Type signatures are solved by unification and then all
occurring constraints are solved. By putting a ~ constraint you explicitly
instruct GHC to not attempt unification.

When using associated type synonyms you need to use ~, as the choice of
TestT a depends on what instance is picked for Test a. There doesn't even
have to be an instance at all. As the unifier is iirc mostly independent
from the constraint solver, you get that error.

See the relevant paper "Associated Type Synonyms" for details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150912/732550dd/attachment.html>

From strake888 at gmail.com  Sat Sep 12 22:14:37 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sat, 12 Sep 2015 14:14:37 -0800
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type 	class
In-Reply-To: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>
References: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>
Message-ID: <20150912221437.GA3904@mintha.lan>

On 12/09/2015 at 14:39:53 +0200, Olaf Klinke wrote:
> I sencond the statement that semirings might be a useful typeclass to have. Another example: Non-negative reals with infinity, the values that a measure can take. Nevertheless the biggest issue is what _symbol_ to use for the operations. We know that a ring is a semigroup in two ways, and no matter what semigroup structure we think the ring to "originate" from, we're going to annoy the other half of users who thought it the other way around. Some semigroups are thought of as (+), others as (*). Picking one of these symbols for all semigroups will be counter-intuitive for some structures. 

Consider this:

class Semigroup a where
    (<>) :: a -> a -> a

newtype Sum a = Sum a

newtype Product a = Product a

(+) :: Semigroup (Sum a) => a -> a -> a
(*) :: Semigroup (Product a) => a -> a -> a

class Semigroup a => Abelian a

-- with ConstraintKinds
type Semiring a = (Abelian (Sum a), Semigroup (Product a))

From anton.kholomiov at gmail.com  Sun Sep 13 09:13:08 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Sun, 13 Sep 2015 12:13:08 +0300
Subject: [Haskell-cafe] the library of beautiful instruments implemented in
	haskell / csound
Message-ID: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>

Status update for my haskell synth csound-expression. The main point is
presence of many cool instruments. They are implemented in the package
csound-catalog. All packages are compiled with GHC-7.10 So the hackage
fails to build them and unfortunately docs a broken too. But you can look
at the source code of the module Csound.Patch to now  the names of the
instruments. The usage is pretty straightforward. It's described here:

https://github.com/spell-music/csound-expression/blob/master/tutorial/chapters/Patches.md

There is an mp3 file to listen to the instruments. http://ge.tt/1jNETqN2/v/0

*The 4.8.3 is out! New features:*

This is a very important release to me. It tries to solve the problem
present in the most open source music-production libraries. It's often the
pack of beautiful sounds/timbres is missing. User is presented with many
audio primitives but no timbres are present to show the real power of the
framework. This release solves this problem. See the friend package
csound-catalog on Hackage. It defines 200+ beautiful instruments ready to
be used.

The csound-expression defines a new type called Patch for description of an
instrument with a chain of effects. It's good place to start the journey to
the world of music production.

There are new functions for synchronized reaction on events. The triggering
of events can be synchronized with given BPM.

The library is updated for GHC-7.10!


github repo: https://github.com/spell-music/csound-expression

hackage: http://hackage.haskell.org/package/csound-expression


Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150913/54973dcd/attachment.html>

From haskell at erebe.eu  Sun Sep 13 10:36:49 2015
From: haskell at erebe.eu (haskell at erebe.eu)
Date: Sun, 13 Sep 2015 12:36:49 +0200
Subject: [Haskell-cafe] haskell est il compatible avec mon projet
 graphique ?
In-Reply-To: <5247aa09-f9e0-4484-8b9d-1558562d7aca@googlegroups.com>
References: <5f14856f-ff7f-4c33-b4b6-298937779046@googlegroups.com>
 <5247aa09-f9e0-4484-8b9d-1558562d7aca@googlegroups.com>
Message-ID: <55F551C1.6020102@erebe.eu>

Salut,

Il y a bien un port sur Haskell de la librairy SDL (tu peux regarder par 
l? 
<https://ocharles.org.uk/blog/posts/2015-09-07-announcing-sdl2.html>), 
mais je trouve que tout ce qui est li? au d?veloppement graphique sur 
Haskell est encore immature, dans le sens ou tout est en perp?tuelle 
?volution.

De plus, si tu d?bute sur Haskell, ne t'attends pas ? avoir quelque 
chose de fonctionnel avant plusieurs grosses semaines (voir mois) de 
travail.

Personnellement, je te conseillerai d'utiliser Python, tu seras beaucoup 
plus ? l'aise au d?part et la nature dynamique du langage te permettre 
de prototype assez rapidement/facilement. Haskell a une courbe 
d'apprentissage assez raide au d?part :(

Romain G?rard

On 12/09/2015 18:46, Daniel D?az wrote:
> Pardonnez mon mauvais fran?ais.
>
> Il existe des liaisons pour SDL2: http://hackage.haskell.org/package/sdl2
>
> Aussi jeter un oeil ? "diagrams" 
>  http://projects.haskell.org/diagrams/gallery.html
>
> On Saturday, September 12, 2015 at 6:17:04 AM UTC+2, Vincent Douce LR 
> wrote:
>
>     salut ? tous
>     je dois r?aliser des cr?ations graphiques, avec deux destinations
>     : des animations sur l'?cran, et des images fixes destin?es ? ?tre
>     publi?es sur papier
>     ces cr?ations reposent sur des algorithmes de mon cr?
>     je souhaite me cr?er une biblioth?que de s?quences de code que je
>     pourrai ?toffer au fur et ? mesure et utiliser dans mes programmes
>     je cherche quel langage adopter, et quel pendant graphique lui
>     adjoindre
>     j'envisage des pistes comme C+sdl ou python +?
>     utiliser haskell serait un d?fi parce que c'est moins intuitif
>     pour moi un langage fonctionnel et aussi tout simplemetn parce que
>     je n'y connais rien en haskell, je sais juste un peu de Scheme
>     mais peut ?tre qu'il y a dans l'univers haskell un moyen de
>     g?n?rer des graphiques de qualit? ? je susi ouvert
>     qu'en pensez-vous ?
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150913/8a1ba5f6/attachment.html>

From agocorona at gmail.com  Sun Sep 13 15:48:57 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Sun, 13 Sep 2015 17:48:57 +0200
Subject: [Haskell-cafe] ANNOUNCE: ioctl 0.0.1
In-Reply-To: <1266709126.29755.44.camel@picard>
References: <1266709126.29755.44.camel@picard>
Message-ID: <CAArEJmaUZnrJgWvWi06QLVufezXs15y+xYTQSi0L7wCj0Q3H1g@mail.gmail.com>

Did you managed to make it available for Windows?

2010-02-21 0:38 GMT+01:00 Maciej Piechotka <uzytkownik2 at gmail.com>:

> A package for type-safe I/O control. Currently only ioctl is supported.
>
> Currently simply a extract from my tuntap fork
>
> TODO:
> - Return the integer as well as structure (will break the API)
> - Port for Windows Network.Socket.IOCtl (as soon as I manage to setup
> some sane environment on this platform)
> - Wrapping around DeviceIoControl
>
> Example (in hsc):
> data NotRead = NotRead
> instance NotRead Int where
>         ioctlReq _ = #const FIONREAD
>
> notRead s = ioctlsocket' s NotRead
>
> Regards
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150913/4f53fa5d/attachment.html>

From olf at aatal-apotheke.de  Sun Sep 13 19:51:17 2015
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sun, 13 Sep 2015 21:51:17 +0200
Subject: [Haskell-cafe] The semiring of Scott reals (Thoughts about
	redesigning "Num" type class)
Message-ID: <5358C806-9798-47EF-A35B-019A8A939F42@aatal-apotheke.de>

This departs somewhat from the thread's topic. Below I detail a semiring R that is not a ring because negation is not definable in Haskell. I further sketch integration in Haskell which I ripped off papers by Gordon Plotkin, Steve Vickers, Anders Kock and others. 

Infinity comes in as a limit, of course. Approximate a real number by an ascending stream of rational numbers. (The ascending can not be enforced by Haskell's type system, of course.). What you have is a so-called lower real or Scott real. Still addition and multiplication is continuous on such reals and there is a unique way of extending these operations to infinity, represented by any strictly ascending stream. Neither subtraction not division are computable for the Scott reals. Indeed, to know a lower bound of x-y one needs to know upper bounds of y. Denote this type by R: 

type R = Stream Rational

Further consider ascending streams of Booleans, where any two streams containing True are considered semantically equivalent. 

type S = Stream Bool

Consider the following types: 

type ScottOpen x = x -> S
type V x = (ScottOpen x) -> R

Certain elements of the type V x are called valuations, assigning to any Scott open subset[*] of x a lower real number. The type constructor V has a monad instance. If there was a one-element type in Haskell (say 1), then V 1 is isomorphic to R. Hence a lower semicontinuous real-valued function f :: x -> R is the same as a function f :: x -> V 1. Now observe that 

  (=<<) :: (x -> V 1) -> V x -> V 1
        :: (x -> R  ) -> V x -> R

has the type of an integral operator. In other words, the bind of the monad V implements integration. I have an implementation that lets you do integration over any Haskell type, but it is very slow. 

An analogue of this is the monad []. Indeed, total elements of type N = [()] are natural numbers. Disregarding permutations, an element of [x] assigns to finitely many elements of x a weight from the natural numbers. Then 

  (=<<) :: (x -> [()]) -> [x] -> [()]
        :: (x -> N   ) -> [x] -> N

is the integral operator integrating natural-number-valued functions against a finite natural-number-valued measure. Further observe that 

  liftM2 (flip const) :: Monad m => m () -> m x -> m x

is a monoid action that implements multiplication on N. It distributes over (++) for categorical reasons: (++) arises from the isomorphism (up to permutation)

   ([a],[b]) -> [Either a b].

As an exercise, define a monad instance for 

type FinDist x = [(x,Rational)]

    Hint: FinDist x = WriterT (Product Rational) [] x

and observe that FinDist () is isomorphic to Rational (up to some equivalence relation). Voila: You have integration of Rational-valued functions against finitely supported distributions. For many combinatorial applications, this is sufficient. 

[*] For u :: x -> S, consider the set of elements of x for which u produces a stream containing True. This is the Scott open subset. Valuations are required to send the empty open to the constant zero stream and further obey the modular law you know from measures: 

  v(u) + v(u') = v(union u u') + v(intersection u u')

where union = liftA2 max and intersection = liftA2 min. 

-- Olaf

From svenpanne at gmail.com  Sun Sep 13 20:13:28 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 13 Sep 2015 22:13:28 +0200
Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages
Message-ID: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>

Currently there are 2 similar packages on Hackage to access raw OpenGL
functionality: OpenGLRaw and gl. Taking a closer look at them, it turns out
that they are only superficially different and have a lot of things in
common. This is a bit confusing for users, so it might make sense to merge
those packages. Therefore I'd like to start a discussion how to do this in
detail, collecting user feedback and opinions. I think that haskell-cafe is
the right place for this discussion, while an accompanying wiki page is
more suitable to collect the results. As a basis I started a page at
https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl,
which is necessarily biased at the moment. ;-) It would be nice to hear
your opinions about how the package should look like, what might be
missing, what could be done better, which differences I forgot, etc.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150913/980c3538/attachment.html>

From mike at izbicki.me  Sun Sep 13 20:21:36 2015
From: mike at izbicki.me (Mike Izbicki)
Date: Sun, 13 Sep 2015 13:21:36 -0700
Subject: [Haskell-cafe] The semiring of Scott reals (Thoughts about
 redesigning "Num" type class)
In-Reply-To: <5358C806-9798-47EF-A35B-019A8A939F42@aatal-apotheke.de>
References: <5358C806-9798-47EF-A35B-019A8A939F42@aatal-apotheke.de>
Message-ID: <CAKKZoUW0hbXVij1jdnfpRUO4u9Jt2s4ZBbbQ7q7Qrd8_qC94Sw@mail.gmail.com>

Two things:

1) My subhask library's reimplementation of the numeric hierarchy is
compatible with the Scott Reals you define.  It can be made an
instance of SubHask's Rig typeclass.  See
https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/Algebra.hs#L1309-L1317

The trickiest thing I've found with numeric hierarchy rewrites is
handling units of measure properly.  There's a good discussion about
this on SubHask's issue tracker:
https://github.com/mikeizbicki/subhask/issues/11

2) WRT to integration, that's cool!  I hadn't thought of the
connection between integration and the bind operation before.

I think we can probably take it a step further.  When you talk about
the list monad "disregarding permutations", what you're actually
talking about is the set monad.  And now that I think about it, it
makes sense that bind on the set monad closely corresponds to the
traditional measure-theoretic view of integration on sets.  So the
interesting follow on question is: can we define integration on
non-set monads?

I've though a bit about defining integration on non-sets before.  My
approach (also used in subhask) was via the Foldable type class.  See
this Cafe thread for more details:
https://mail.haskell.org/pipermail/haskell-cafe/2015-March/118471.html

Something I haven't done is connect this with the monad instance for
the type we're integrating over... but now I'm definitely going to
look into it :)

On Sun, Sep 13, 2015 at 12:51 PM, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> This departs somewhat from the thread's topic. Below I detail a semiring R that is not a ring because negation is not definable in Haskell. I further sketch integration in Haskell which I ripped off papers by Gordon Plotkin, Steve Vickers, Anders Kock and others.
>
> Infinity comes in as a limit, of course. Approximate a real number by an ascending stream of rational numbers. (The ascending can not be enforced by Haskell's type system, of course.). What you have is a so-called lower real or Scott real. Still addition and multiplication is continuous on such reals and there is a unique way of extending these operations to infinity, represented by any strictly ascending stream. Neither subtraction not division are computable for the Scott reals. Indeed, to know a lower bound of x-y one needs to know upper bounds of y. Denote this type by R:
>
> type R = Stream Rational
>
> Further consider ascending streams of Booleans, where any two streams containing True are considered semantically equivalent.
>
> type S = Stream Bool
>
> Consider the following types:
>
> type ScottOpen x = x -> S
> type V x = (ScottOpen x) -> R
>
> Certain elements of the type V x are called valuations, assigning to any Scott open subset[*] of x a lower real number. The type constructor V has a monad instance. If there was a one-element type in Haskell (say 1), then V 1 is isomorphic to R. Hence a lower semicontinuous real-valued function f :: x -> R is the same as a function f :: x -> V 1. Now observe that
>
>   (=<<) :: (x -> V 1) -> V x -> V 1
>         :: (x -> R  ) -> V x -> R
>
> has the type of an integral operator. In other words, the bind of the monad V implements integration. I have an implementation that lets you do integration over any Haskell type, but it is very slow.
>
> An analogue of this is the monad []. Indeed, total elements of type N = [()] are natural numbers. Disregarding permutations, an element of [x] assigns to finitely many elements of x a weight from the natural numbers. Then
>
>   (=<<) :: (x -> [()]) -> [x] -> [()]
>         :: (x -> N   ) -> [x] -> N
>
> is the integral operator integrating natural-number-valued functions against a finite natural-number-valued measure. Further observe that
>
>   liftM2 (flip const) :: Monad m => m () -> m x -> m x
>
> is a monoid action that implements multiplication on N. It distributes over (++) for categorical reasons: (++) arises from the isomorphism (up to permutation)
>
>    ([a],[b]) -> [Either a b].
>
> As an exercise, define a monad instance for
>
> type FinDist x = [(x,Rational)]
>
>     Hint: FinDist x = WriterT (Product Rational) [] x
>
> and observe that FinDist () is isomorphic to Rational (up to some equivalence relation). Voila: You have integration of Rational-valued functions against finitely supported distributions. For many combinatorial applications, this is sufficient.
>
> [*] For u :: x -> S, consider the set of elements of x for which u produces a stream containing True. This is the Scott open subset. Valuations are required to send the empty open to the constant zero stream and further obey the modular law you know from measures:
>
>   v(u) + v(u') = v(union u u') + v(intersection u u')
>
> where union = liftA2 max and intersection = liftA2 min.
>
> -- Olaf
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From amindfv at gmail.com  Sun Sep 13 21:38:28 2015
From: amindfv at gmail.com (Tom Murphy)
Date: Sun, 13 Sep 2015 21:38:28 +0000
Subject: [Haskell-cafe] the library of beautiful instruments implemented
 in haskell / csound
In-Reply-To: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>
References: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>
Message-ID: <CAO9Q0tXgjia=C-gVipDQPBcMgcWGMN4BkH0_VpU9=D_KAfva8w@mail.gmail.com>

These sound great, congratulations! "Batteries included" is a great place
to be. Can you point to references you used to create the instrument
definitions?

Tom


On Sun, Sep 13, 2015 at 9:13 AM, Anton Kholomiov <anton.kholomiov at gmail.com>
wrote:

> Status update for my haskell synth csound-expression. The main point is
> presence of many cool instruments. They are implemented in the package
> csound-catalog. All packages are compiled with GHC-7.10 So the hackage
> fails to build them and unfortunately docs a broken too. But you can look
> at the source code of the module Csound.Patch to now  the names of the
> instruments. The usage is pretty straightforward. It's described here:
>
>
> https://github.com/spell-music/csound-expression/blob/master/tutorial/chapters/Patches.md
>
> There is an mp3 file to listen to the instruments.
> http://ge.tt/1jNETqN2/v/0
>
> *The 4.8.3 is out! New features:*
>
> This is a very important release to me. It tries to solve the problem
> present in the most open source music-production libraries. It's often the
> pack of beautiful sounds/timbres is missing. User is presented with many
> audio primitives but no timbres are present to show the real power of the
> framework. This release solves this problem. See the friend package
> csound-catalog on Hackage. It defines 200+ beautiful instruments ready to
> be used.
>
> The csound-expression defines a new type called Patch for description of
> an instrument with a chain of effects. It's good place to start the journey
> to the world of music production.
>
> There are new functions for synchronized reaction on events. The
> triggering of events can be synchronized with given BPM.
>
> The library is updated for GHC-7.10!
>
>
> github repo: https://github.com/spell-music/csound-expression
>
> hackage: http://hackage.haskell.org/package/csound-expression
>
>
> Cheers!
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150913/dd47c2b4/attachment.html>

From ok at cs.otago.ac.nz  Mon Sep 14 02:17:27 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon, 14 Sep 2015 14:17:27 +1200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
Message-ID: <4CF0BE86-1436-4FDB-96DD-4DE7AF846EB4@cs.otago.ac.nz>

Without taking a stand, I note that Clean has one class
per "arithmetic" function.

I also note that Money / Money -> Number (not Money)
and if Money * Money -> something, it certainly isn't Money.
Similarly, DateAndTime ? Duration -> DateAndTime,
and DateAndTime - DateAndTime -> Duration, but
DateAndTime + DateAndTime does not make sense.
(DateAndTime and Duration come from Smalltalk.)

I've chosen these examples because they are not "metaphorical"
overloadings of the operators.  They do obey natural axioms.
E.g., now + (now - now) = now, now + (dur*2) = (now+dur)+dur.
(Assuming exact numbers underneath.)

Sounds like multi-parameter typeclasses are going to be vital
for a restructuring of the numeric classes.


From anton.kholomiov at gmail.com  Mon Sep 14 10:11:14 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Mon, 14 Sep 2015 13:11:14 +0300
Subject: [Haskell-cafe] the library of beautiful instruments implemented
 in haskell / csound
In-Reply-To: <CAO9Q0tXgjia=C-gVipDQPBcMgcWGMN4BkH0_VpU9=D_KAfva8w@mail.gmail.com>
References: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>
 <CAO9Q0tXgjia=C-gVipDQPBcMgcWGMN4BkH0_VpU9=D_KAfva8w@mail.gmail.com>
Message-ID: <CADDxdqPWHu8_siMau=5GFmAAOcV3n+kZ0yW+5QqPPqu6sCJ=Xg@mail.gmail.com>

Thanks for feedback. I've used several sources on sound design:

Ian McCurdy collection of csound instruments:
http://iainmccurdy.org/csound.html

Thor demystified series by Gordon Reid:
https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article

Csound pieces from Csound Catalog: http://www.csounds.com/csound-catalog/

Olav Basoski course: https://www.macprovideo.com/tutorial/live8402

Sound on sound synth secrets:
http://www.soundonsound.com/sos/allsynthsecrets.htm

Risset' Amsterdam Collection of Csound Instruments:
http://www.codemist.co.uk/AmsterdamCatalog/

It's mostly Iain McCurdy instruments, thor demystified series, and
instruments from various pieces
by Csounders (Csound catalog)




2015-09-14 0:38 GMT+03:00 Tom Murphy <amindfv at gmail.com>:

> These sound great, congratulations! "Batteries included" is a great place
> to be. Can you point to references you used to create the instrument
> definitions?
>
> Tom
>
>
> On Sun, Sep 13, 2015 at 9:13 AM, Anton Kholomiov <
> anton.kholomiov at gmail.com> wrote:
>
>> Status update for my haskell synth csound-expression. The main point is
>> presence of many cool instruments. They are implemented in the package
>> csound-catalog. All packages are compiled with GHC-7.10 So the hackage
>> fails to build them and unfortunately docs a broken too. But you can look
>> at the source code of the module Csound.Patch to now  the names of the
>> instruments. The usage is pretty straightforward. It's described here:
>>
>>
>> https://github.com/spell-music/csound-expression/blob/master/tutorial/chapters/Patches.md
>>
>> There is an mp3 file to listen to the instruments.
>> http://ge.tt/1jNETqN2/v/0
>>
>> *The 4.8.3 is out! New features:*
>>
>> This is a very important release to me. It tries to solve the problem
>> present in the most open source music-production libraries. It's often the
>> pack of beautiful sounds/timbres is missing. User is presented with many
>> audio primitives but no timbres are present to show the real power of the
>> framework. This release solves this problem. See the friend package
>> csound-catalog on Hackage. It defines 200+ beautiful instruments ready to
>> be used.
>>
>> The csound-expression defines a new type called Patch for description of
>> an instrument with a chain of effects. It's good place to start the journey
>> to the world of music production.
>>
>> There are new functions for synchronized reaction on events. The
>> triggering of events can be synchronized with given BPM.
>>
>> The library is updated for GHC-7.10!
>>
>>
>> github repo: https://github.com/spell-music/csound-expression
>>
>> hackage: http://hackage.haskell.org/package/csound-expression
>>
>>
>> Cheers!
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/02568d80/attachment.html>

From anton.kholomiov at gmail.com  Mon Sep 14 10:15:11 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Mon, 14 Sep 2015 13:15:11 +0300
Subject: [Haskell-cafe] the library of beautiful instruments implemented
 in haskell / csound
In-Reply-To: <CADDxdqPWHu8_siMau=5GFmAAOcV3n+kZ0yW+5QqPPqu6sCJ=Xg@mail.gmail.com>
References: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>
 <CAO9Q0tXgjia=C-gVipDQPBcMgcWGMN4BkH0_VpU9=D_KAfva8w@mail.gmail.com>
 <CADDxdqPWHu8_siMau=5GFmAAOcV3n+kZ0yW+5QqPPqu6sCJ=Xg@mail.gmail.com>
Message-ID: <CADDxdqNbpCnOqFO=eNvFkZouerbdgKf2Z6wuBYxvqm2-A_PFoQ@mail.gmail.com>

It's all was played live with Csound triggered by midi keyboard and
recorded with Audacity (connected to csound output with Jack)

2015-09-14 13:11 GMT+03:00 Anton Kholomiov <anton.kholomiov at gmail.com>:

> Thanks for feedback. I've used several sources on sound design:
>
> Ian McCurdy collection of csound instruments:
> http://iainmccurdy.org/csound.html
>
> Thor demystified series by Gordon Reid:
> https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article
>
> Csound pieces from Csound Catalog: http://www.csounds.com/csound-catalog/
>
> Olav Basoski course: https://www.macprovideo.com/tutorial/live8402
>
> Sound on sound synth secrets:
> http://www.soundonsound.com/sos/allsynthsecrets.htm
>
> Risset' Amsterdam Collection of Csound Instruments:
> http://www.codemist.co.uk/AmsterdamCatalog/
>
> It's mostly Iain McCurdy instruments, thor demystified series, and
> instruments from various pieces
> by Csounders (Csound catalog)
>
>
>
>
> 2015-09-14 0:38 GMT+03:00 Tom Murphy <amindfv at gmail.com>:
>
>> These sound great, congratulations! "Batteries included" is a great place
>> to be. Can you point to references you used to create the instrument
>> definitions?
>>
>> Tom
>>
>>
>> On Sun, Sep 13, 2015 at 9:13 AM, Anton Kholomiov <
>> anton.kholomiov at gmail.com> wrote:
>>
>>> Status update for my haskell synth csound-expression. The main point is
>>> presence of many cool instruments. They are implemented in the package
>>> csound-catalog. All packages are compiled with GHC-7.10 So the hackage
>>> fails to build them and unfortunately docs a broken too. But you can look
>>> at the source code of the module Csound.Patch to now  the names of the
>>> instruments. The usage is pretty straightforward. It's described here:
>>>
>>>
>>> https://github.com/spell-music/csound-expression/blob/master/tutorial/chapters/Patches.md
>>>
>>> There is an mp3 file to listen to the instruments.
>>> http://ge.tt/1jNETqN2/v/0
>>>
>>> *The 4.8.3 is out! New features:*
>>>
>>> This is a very important release to me. It tries to solve the problem
>>> present in the most open source music-production libraries. It's often the
>>> pack of beautiful sounds/timbres is missing. User is presented with many
>>> audio primitives but no timbres are present to show the real power of the
>>> framework. This release solves this problem. See the friend package
>>> csound-catalog on Hackage. It defines 200+ beautiful instruments ready to
>>> be used.
>>>
>>> The csound-expression defines a new type called Patch for description
>>> of an instrument with a chain of effects. It's good place to start the
>>> journey to the world of music production.
>>>
>>> There are new functions for synchronized reaction on events. The
>>> triggering of events can be synchronized with given BPM.
>>>
>>> The library is updated for GHC-7.10!
>>>
>>>
>>> github repo: https://github.com/spell-music/csound-expression
>>>
>>> hackage: http://hackage.haskell.org/package/csound-expression
>>>
>>>
>>> Cheers!
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/858a7343/attachment.html>

From amindfv at gmail.com  Mon Sep 14 14:31:16 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 14 Sep 2015 10:31:16 -0400
Subject: [Haskell-cafe] the library of beautiful instruments implemented
	in haskell / csound
In-Reply-To: <CADDxdqNbpCnOqFO=eNvFkZouerbdgKf2Z6wuBYxvqm2-A_PFoQ@mail.gmail.com>
References: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>
 <CAO9Q0tXgjia=C-gVipDQPBcMgcWGMN4BkH0_VpU9=D_KAfva8w@mail.gmail.com>
 <CADDxdqPWHu8_siMau=5GFmAAOcV3n+kZ0yW+5QqPPqu6sCJ=Xg@mail.gmail.com>
 <CADDxdqNbpCnOqFO=eNvFkZouerbdgKf2Z6wuBYxvqm2-A_PFoQ@mail.gmail.com>
Message-ID: <F6B4E09E-F572-476A-ACB4-1FD062410E10@gmail.com>

Oh interesting! I had thought CSound didn't do realtime synthesis.

tom


El Sep 14, 2015, a las 6:15, Anton Kholomiov <anton.kholomiov at gmail.com> escribi?:

> It's all was played live with Csound triggered by midi keyboard and recorded with Audacity (connected to csound output with Jack)
> 
> 2015-09-14 13:11 GMT+03:00 Anton Kholomiov <anton.kholomiov at gmail.com>:
>> Thanks for feedback. I've used several sources on sound design:
>> 
>> Ian McCurdy collection of csound instruments: http://iainmccurdy.org/csound.html
>> 
>> Thor demystified series by Gordon Reid: https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article
>> 
>> Csound pieces from Csound Catalog: http://www.csounds.com/csound-catalog/
>> 
>> Olav Basoski course: https://www.macprovideo.com/tutorial/live8402
>> 
>> Sound on sound synth secrets: http://www.soundonsound.com/sos/allsynthsecrets.htm
>> 
>> Risset' Amsterdam Collection of Csound Instruments: http://www.codemist.co.uk/AmsterdamCatalog/
>> 
>> It's mostly Iain McCurdy instruments, thor demystified series, and instruments from various pieces 
>> by Csounders (Csound catalog)
>> 
>> 
>> 
>> 
>> 2015-09-14 0:38 GMT+03:00 Tom Murphy <amindfv at gmail.com>:
>>> These sound great, congratulations! "Batteries included" is a great place to be. Can you point to references you used to create the instrument definitions?
>>> 
>>> Tom
>>> 
>>> 
>>> On Sun, Sep 13, 2015 at 9:13 AM, Anton Kholomiov <anton.kholomiov at gmail.com> wrote:
>>>> Status update for my haskell synth csound-expression. The main point is presence of many cool instruments. They are implemented in the package csound-catalog. All packages are compiled with GHC-7.10 So the hackage fails to build them and unfortunately docs a broken too. But you can look at the source code of the module Csound.Patch to now  the names of the instruments. The usage is pretty straightforward. It's described here:
>>>> 
>>>> https://github.com/spell-music/csound-expression/blob/master/tutorial/chapters/Patches.md
>>>> 
>>>> There is an mp3 file to listen to the instruments. http://ge.tt/1jNETqN2/v/0
>>>> 
>>>> The 4.8.3 is out! New features:
>>>> 
>>>> This is a very important release to me. It tries to solve the problem present in the most open source music-production libraries. It's often the pack of beautiful sounds/timbres is missing. User is presented with many audio primitives but no timbres are present to show the real power of the framework. This release solves this problem. See the friend package csound-catalog on Hackage. It defines 200+ beautiful instruments ready to be used.
>>>> 
>>>> The csound-expression defines a new type called Patch for description of an instrument with a chain of effects. It's good place to start the journey to the world of music production.
>>>> 
>>>> There are new functions for synchronized reaction on events. The triggering of events can be synchronized with given BPM.
>>>> 
>>>> The library is updated for GHC-7.10!
>>>> 
>>>> 
>>>> 
>>>> github repo: https://github.com/spell-music/csound-expression
>>>> 
>>>> hackage: http://hackage.haskell.org/package/csound-expression
>>>> 
>>>> 
>>>> 
>>>> Cheers!
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/05482e2e/attachment.html>

From anton.kholomiov at gmail.com  Mon Sep 14 14:56:30 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Mon, 14 Sep 2015 17:56:30 +0300
Subject: [Haskell-cafe] the library of beautiful instruments implemented
 in haskell / csound
In-Reply-To: <F6B4E09E-F572-476A-ACB4-1FD062410E10@gmail.com>
References: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>
 <CAO9Q0tXgjia=C-gVipDQPBcMgcWGMN4BkH0_VpU9=D_KAfva8w@mail.gmail.com>
 <CADDxdqPWHu8_siMau=5GFmAAOcV3n+kZ0yW+5QqPPqu6sCJ=Xg@mail.gmail.com>
 <CADDxdqNbpCnOqFO=eNvFkZouerbdgKf2Z6wuBYxvqm2-A_PFoQ@mail.gmail.com>
 <F6B4E09E-F572-476A-ACB4-1FD062410E10@gmail.com>
Message-ID: <CADDxdqO7x1puNVKRAa64ePa2XdWyBS=CrSbMtfm5sCC2futEnQ@mail.gmail.com>

Yes, it can work in real time! There is even an Android app that uses
Csound in real-time. It's called EtherPad. And a couple of iOS  apps:
csGrain and csSpectral

http://www.youtube.com/watch?v=SZ7Tbc8dIsg
http://www.boulangerlabs.com/

Though some instruments require  lots of CPU.
With Jack I was able to stream the audio to DAW live.

2015-09-14 17:31 GMT+03:00 <amindfv at gmail.com>:

> Oh interesting! I had thought CSound didn't do realtime synthesis.
>
> tom
>
>
> El Sep 14, 2015, a las 6:15, Anton Kholomiov <anton.kholomiov at gmail.com>
> escribi?:
>
> It's all was played live with Csound triggered by midi keyboard and
> recorded with Audacity (connected to csound output with Jack)
>
> 2015-09-14 13:11 GMT+03:00 Anton Kholomiov <anton.kholomiov at gmail.com>:
>
>> Thanks for feedback. I've used several sources on sound design:
>>
>> Ian McCurdy collection of csound instruments:
>> http://iainmccurdy.org/csound.html
>>
>> Thor demystified series by Gordon Reid:
>> https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article
>>
>> Csound pieces from Csound Catalog: http://www.csounds.com/csound-catalog/
>>
>> Olav Basoski course: https://www.macprovideo.com/tutorial/live8402
>>
>> Sound on sound synth secrets:
>> http://www.soundonsound.com/sos/allsynthsecrets.htm
>>
>> Risset' Amsterdam Collection of Csound Instruments:
>> http://www.codemist.co.uk/AmsterdamCatalog/
>>
>> It's mostly Iain McCurdy instruments, thor demystified series, and
>> instruments from various pieces
>> by Csounders (Csound catalog)
>>
>>
>>
>>
>> 2015-09-14 0:38 GMT+03:00 Tom Murphy <amindfv at gmail.com>:
>>
>>> These sound great, congratulations! "Batteries included" is a great
>>> place to be. Can you point to references you used to create the instrument
>>> definitions?
>>>
>>> Tom
>>>
>>>
>>> On Sun, Sep 13, 2015 at 9:13 AM, Anton Kholomiov <
>>> anton.kholomiov at gmail.com> wrote:
>>>
>>>> Status update for my haskell synth csound-expression. The main point is
>>>> presence of many cool instruments. They are implemented in the package
>>>> csound-catalog. All packages are compiled with GHC-7.10 So the hackage
>>>> fails to build them and unfortunately docs a broken too. But you can look
>>>> at the source code of the module Csound.Patch to now  the names of the
>>>> instruments. The usage is pretty straightforward. It's described here:
>>>>
>>>>
>>>> https://github.com/spell-music/csound-expression/blob/master/tutorial/chapters/Patches.md
>>>>
>>>> There is an mp3 file to listen to the instruments.
>>>> http://ge.tt/1jNETqN2/v/0
>>>>
>>>> *The 4.8.3 is out! New features:*
>>>>
>>>> This is a very important release to me. It tries to solve the problem
>>>> present in the most open source music-production libraries. It's often the
>>>> pack of beautiful sounds/timbres is missing. User is presented with many
>>>> audio primitives but no timbres are present to show the real power of the
>>>> framework. This release solves this problem. See the friend package
>>>> csound-catalog on Hackage. It defines 200+ beautiful instruments ready to
>>>> be used.
>>>>
>>>> The csound-expression defines a new type called Patch for description
>>>> of an instrument with a chain of effects. It's good place to start the
>>>> journey to the world of music production.
>>>>
>>>> There are new functions for synchronized reaction on events. The
>>>> triggering of events can be synchronized with given BPM.
>>>>
>>>> The library is updated for GHC-7.10!
>>>>
>>>>
>>>> github repo: https://github.com/spell-music/csound-expression
>>>>
>>>> hackage: http://hackage.haskell.org/package/csound-expression
>>>>
>>>>
>>>> Cheers!
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/ddb83c06/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Mon Sep 14 18:17:08 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Mon, 14 Sep 2015 20:17:08 +0200
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <4CF0BE86-1436-4FDB-96DD-4DE7AF846EB4@cs.otago.ac.nz>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
 <4CF0BE86-1436-4FDB-96DD-4DE7AF846EB4@cs.otago.ac.nz>
Message-ID: <55F70F24.9040605@unicaen.fr>

The NeverEnding story never ends. Good!

Le 14/09/2015 04:17, Richard A. O'Keefe a ?crit :
> Without taking a stand, I note that Clean has one class
> per "arithmetic" function.
This should not be understood too rigidly, we can combine various 
sectors under one name, e.g.,

class Determinant a | *, -, fromInt a

-- as exemplified in the Clean book on FP, page 85. This is a shortcut, 
but replaces Haskell classes with many members.

> I also note that Money / Money -> Number (not Money)
> and if Money * Money -> something, it certainly isn't Money.
> Similarly, DateAndTime ? Duration -> DateAndTime,
> and DateAndTime - DateAndTime -> Duration, but
> DateAndTime + DateAndTime does not make sense.
> (DateAndTime and Duration come from Smalltalk.)
>
> I've chosen these examples because they are not "metaphorical"
> overloadings of the operators.  They do obey natural axioms.
> E.g., now + (now - now) = now, now + (dur*2) = (now+dur)+dur.
> (Assuming exact numbers underneath.)
>
> Sounds like multi-parameter typeclasses are going to be vital
> for a restructuring of the numeric classes.

I am afraid that multi-parameter classes will not "save" anything 
without some precision concerning types themselves. As I say from time 
to time, physicists live with similar questions for centuries, in the 
context of physical units.

Money*Money is strange. But what about  time*time? mass*mass? The 
gravitational constant G has the dimension m^3 kg^(-1) s^(-2). But only 
in SI, and related system.

You find all possible powers, of dimensional quantities, depending on 
your choice of *fundamental* unities. I learnt in school the 
MKS/electrostat system, where an electric charge had the dimension of 
the square root of force, m^(3/2) kg^(1/2) s^(-1). Later, studying 
quantum electrodynamics, I assimilated the "truth", that electric charge 
is just a number, dimensionless. Why?

Because physicists have no reluctance to use UNIVERSAL constants as pure 
numbers, which redefines meters, seconds, etc. : the speed of light is 
1. The Planck constant is 1 as well. And the electric charge becomes 
dimensionless.

Cosmologists add G=1, and all dynamical quantities become dimensionless, 
no more meters, seconds, kilograms. Just numbers. They write formulae, 
where some quantity is proportional to the logarithm of time. This may 
disturb even those who accept non-integral powers of length. Is it 
"cheating", implying log(t/t_0), where the denominator reduces the time 
unit?

What about fractal objects with abominable dimensions, say 
m^(1.2654132089) ?
And such things exist in physics, they are called, for example, 
anomalous dimensions, measurable.

If we decide that there exists universally One Currency to Rule Them 
All, say, Renminbi,  then
money + money*money + 1/money + exp(-money) becomes computable.

Of course, you will not measure your waist in Planck length units 
(although for myself, year after year, it becomes less crazy), but all 
this is not a trivial issue.

==

This is another reason (the first was torsors) why I don't believe in 
too simplistic playing with straitjackets, forbidding some operations in 
the name of "coherence".  DateTime vs Duration is another version of the 
point/vector discussion, or vector vs. affine spaces. Thousands of texts 
covered all that...

Jerzy Karczmarczuk



^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/a4d9987f/attachment.html>

From jorgemal1960 at gmail.com  Mon Sep 14 18:57:10 2015
From: jorgemal1960 at gmail.com (JORGE MALDONADO)
Date: Mon, 14 Sep 2015 13:57:10 -0500
Subject: [Haskell-cafe] Powerset of a set
Message-ID: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>

The powerset of set s is a set containing all subsets of s.
I need a clue on how to write Haskell code to get the superset of a set
using direct recursion and list comprehension.

Best regads.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/acd94b28/attachment.html>

From fa-ml at ariis.it  Mon Sep 14 19:18:55 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Mon, 14 Sep 2015 21:18:55 +0200
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
Message-ID: <20150914191855.GA8615@casa.casa>

On Mon, Sep 14, 2015 at 01:57:10PM -0500, JORGE MALDONADO wrote:
> The powerset of set s is a set containing all subsets of s.
> I need a clue on how to write Haskell code to get the superset of a set
> using direct recursion and list comprehension.
> 
> Best regads.

This is good for haskell-beginners rather than haskell cafe.

Clue:
    - say you have a list `l` [a,b,c,d,e]
    - you have the powerset of list `m` [b,c,d,e]
    - how can you use the `powerset of m` to calculate the `powerset of l`?

From trebla at vex.net  Mon Sep 14 19:23:44 2015
From: trebla at vex.net (Albert Y. C. Lai)
Date: Mon, 14 Sep 2015 15:23:44 -0400
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
Message-ID: <55F71EC0.5020506@vex.net>

On 2015-09-14 02:57 PM, JORGE MALDONADO wrote:
> The powerset of set s is a set containing all subsets of s.
> I need a clue on how to write Haskell code to get the superset of a 
> set using direct recursion and list comprehension.

"superset"? "subsets"?

To compute all subsets of x:xs, i.e., "powerset (x:xs) = ?" :

Suppose powerset xs correctly answers you all subsets of xs. How do you 
build upon its answer to obtain all subsets of x:xs?

Basically, each subset of xs is also a subset of x:xs, so you want to 
include them in your answer for x:xs.

On top of that, for each subset of xs, you can insert x and get a subset 
of x:xs, too.

Does this cover all cases?

From jerzy.karczmarczuk at unicaen.fr  Mon Sep 14 19:48:41 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Mon, 14 Sep 2015 21:48:41 +0200
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
Message-ID: <55F72499.80505@unicaen.fr>



Le 14/09/2015 20:57, JORGE MALDONADO a ?crit :
> The powerset of set s is a set containing all subsets of s.
> I need a clue on how to write Haskell code to get the superset of a 
> set using direct recursion and list comprehension.
Clue?...

Three years ago.

http://stackoverflow.com/questions/11988184/how-is-this-power-set-generating-function-working

Three years ago.

http://chaos.weblogs.us/archives/354

etc.

Would you mind explaining us, Jorge Maldonaldo, why couldn't you find 
this by yourself? Is Google so difficult to use?

Jerzy Karczmarczuk


From fa-ml at ariis.it  Mon Sep 14 21:04:37 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Mon, 14 Sep 2015 23:04:37 +0200
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <55F72499.80505@unicaen.fr>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
 <55F72499.80505@unicaen.fr>
Message-ID: <20150914210437.GA1480@casa.casa>

On Mon, Sep 14, 2015 at 09:48:41PM +0200, Jerzy Karczmarczuk wrote:
> Le 14/09/2015 20:57, JORGE MALDONADO a ?crit :
> >The powerset of set s is a set containing all subsets of s.
> >I need a clue on how to write Haskell code to get the superset of a set
> >using direct recursion and list comprehension.
> Clue?...
> 
> Three years ago.
> 
> http://stackoverflow.com/questions/11988184/how-is-this-power-set-generating-function-working
> 
> Three years ago.
> 
> http://chaos.weblogs.us/archives/354
> 
> etc.
> 
> Would you mind explaining us, Jorge Maldonaldo, why couldn't you find this
> by yourself? Is Google so difficult to use?

Clue /= solution. Searching the web tentds to give straight answers
rather than hints (which some of us find more useful to progress).

From jerzy.karczmarczuk at unicaen.fr  Mon Sep 14 21:41:09 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Mon, 14 Sep 2015 23:41:09 +0200
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <20150914210437.GA1480@casa.casa>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
 <55F72499.80505@unicaen.fr> <20150914210437.GA1480@casa.casa>
Message-ID: <55F73EF5.2080204@unicaen.fr>



Le 14/09/2015 23:04, Francesco Ariis follows my cold remark suggesting 
that JM should look upon some sources before asking this list to help to 
solve his homework:

> Clue /= solution. Searching the web tentds to give straight answers 
> rather than hints (which some of us find more useful to progress

?

Did *YOU*, Francesco Ariis, verify the references cited? You reproach me 
of WHAT?

The StackOverflow page gives plenty of clues, a little theory, data 
properties, etc.

On the Web you will find what you wish to find. If you don't want 
hamburger solutions, don't read them.  If for you it is more "useful to 
progress", by querying a community which should be, and IS helpful, but 
will not replace your ELEMENTARY textbooks, and your teachers, I don't 
think we share the same vocabulary.

Jerzy Karczmarczuk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/b62d76ad/attachment.html>

From byorgey at gmail.com  Mon Sep 14 21:45:48 2015
From: byorgey at gmail.com (Brent Yorgey)
Date: Mon, 14 Sep 2015 21:45:48 +0000
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <55F72499.80505@unicaen.fr>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
 <55F72499.80505@unicaen.fr>
Message-ID: <CAH0njdubznD3HxBNbnyWxWxK1=rf5=2TiEp+QhP25XSBneCXvA@mail.gmail.com>

Jerzy, you have been on this list long enough to know that is not an
appropriate tone to use when responding to people asking questions.  I am
not disagreeing with the *content* of your message --- indeed, the original
message sounded a lot like asking the list to solve a homework problem.
But your response seemed unnecessarily sarcastic and condescending.

-Brent

On Mon, Sep 14, 2015 at 2:49 PM Jerzy Karczmarczuk <
jerzy.karczmarczuk at unicaen.fr> wrote:

>
>
> Le 14/09/2015 20:57, JORGE MALDONADO a ?crit :
> > The powerset of set s is a set containing all subsets of s.
> > I need a clue on how to write Haskell code to get the superset of a
> > set using direct recursion and list comprehension.
> Clue?...
>
> Three years ago.
>
>
> http://stackoverflow.com/questions/11988184/how-is-this-power-set-generating-function-working
>
> Three years ago.
>
> http://chaos.weblogs.us/archives/354
>
> etc.
>
> Would you mind explaining us, Jorge Maldonaldo, why couldn't you find
> this by yourself? Is Google so difficult to use?
>
> Jerzy Karczmarczuk
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150914/dacc1e4d/attachment.html>

From hjgtuyl at chello.nl  Mon Sep 14 22:51:43 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Tue, 15 Sep 2015 00:51:43 +0200
Subject: [Haskell-cafe] Haskell related search engines in the Opera browser
Message-ID: <op.x4y5sln5pz0j5l@alquantor>


L.S.,

It is easy to define the search facility of the Haskell wiki as a search  
engine in the Opera browser. Press alt-p to get to the preferences panel  
(details differ per Opera version) and define the following parameters for  
the new search engine:
   Name    HaskellWiki
   Keyword hw
   Address https://wiki.haskell.org/Special:Search?search=%s

Now you can enter, for example,
   hw wxHaskell
on the URL bar, to get to the wxHaskell page on the Haskell wiki.
Another option is to double click a word on a web page, right click on the  
word and select Search with -> HaskellWiki.

Similarly, you can search with Hoogle:
   Name    Hoogle
   Keyword h
   Address http://www.stackage.org/lts-2.22/hoogle?q=%s

Hackage:
   Name    HackageDB
   Keyword hd
   Address https://hackage.haskell.org/package/%s

Hayoo:
   Name    Hayoo
   Keyword hay
   Address http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=%s

Regards,
Henk-Jan van Tuyl


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From jerzy.karczmarczuk at unicaen.fr  Mon Sep 14 22:55:53 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 15 Sep 2015 00:55:53 +0200
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <CAH0njdubznD3HxBNbnyWxWxK1=rf5=2TiEp+QhP25XSBneCXvA@mail.gmail.com>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
 <55F72499.80505@unicaen.fr>
 <CAH0njdubznD3HxBNbnyWxWxK1=rf5=2TiEp+QhP25XSBneCXvA@mail.gmail.com>
Message-ID: <55F75079.2020301@unicaen.fr>


Le 14/09/2015 23:45, Brent Yorgey a ?crit :
> you have been on this list long enough to know that is not an 
> appropriate tone to use when responding to people asking questions. 
> /.../  your response seemed unnecessarily sarcastic and condescending.

I am sorry. It was not my purpose to offend anybody,  *sincerely*. If I 
might have been understood in such a way, I apologize.
But, Brent, please : there was no question to answer. Jorge M. said: "I 
need a clue...".  I gave him, indirectly.
I responded thus after having read the answers by Albert Lai, OK, but 
short, probably worth completing, and the second one, by Francesco 
Ariis, which was not a clue at all, it simply said "use recursion", 
while Jorge Maldonado explicitly said that he would use recursion...

+.

Jerzy


From ok at cs.otago.ac.nz  Tue Sep 15 02:03:21 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Tue, 15 Sep 2015 14:03:21 +1200
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
Message-ID: <D25B00F2-4075-4D9A-A785-32803438F416@cs.otago.ac.nz>


On 15/09/2015, at 6:57 am, JORGE MALDONADO <jorgemal1960 at gmail.com> wrote:

> The powerset of set s is a set containing all subsets of s.
> I need a clue on how to write Haskell code to get the superset of a set using direct recursion and list comprehension.


Here is a clue.
>> The question is not well posed.

What is the representation of sets going into your function?
What is the representation of sets coming out of your function?

You could, for example, perform the operation in constant time
by playing games with representations: given a representation of
a set, return a wrapper containing that represent

   typeclass Eq t => Set t
      where is_element :: t -> Set t -> Bool

   instance Eq t => Set [t]
      where is_element = elem

   newtype Power t = Power t

   instance Set t => Set (Power t)
      where is_element x (Power s) = is_subset x s

(Very rough sketch done in haste.)  We can throw in a direct
recursion (in the definition of is_subset, perhaps) and a list
comprehension if you like.

I am not suggesting that you *should* do this, but that your
problem as stated *does not rule this out* as (the beginnings of)
an answer.

So start by spelling out what you are going to use to represent
a set and *how* one of those represents the set it does.  Then
think about the calculation you want to do *in terms of sets*,
not your representation.

 P {} = {{}}
 P ({x} U s) = something involving x, s, and P s.

You also need to be clear about what it is that you are doing.
Are you building some code that you expect to use in a real
program?  In that case, what is this going to cost you?  (Hint:
if |s| = n, what is |P s|?)  If you are doing homework, what is
going to get you marks?  Surely, it is demonstrating understanding.
In this case, yo seem to be asked to show that you understand
recursion, and list comprehensions.

The (incomplete) definition of the power set of a finite set
given above (P) is naturally recursive.  What makes it a good
recursion is that the cases are clearly distinct and the
recursive call (P s) has an argument that is strictly smaller
than what you started with ({x} U s) provided of course that
x is not an element of s.  What makes it a questionable definition
is that it seems to depend on which x we pick.  But does it?
You need to *argue* that

   P({}) = {{}}
   P({x} U s) = something involving x, s, and P(s)
      for *any* partition of a non-empty set n into {x} and s = n\{x}.

Then your code can pick whatever x is easiest to find in the
data structure you're using to represent a set.

Final thought.
If  p1 [1,2] = [[],[1],[2],[1,2]]
and p2 [1,2] = [[2,1],[2],[1],[]]
are they *both* good answers, or neither, or just one?




From ky3 at atamo.com  Tue Sep 15 04:24:32 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 15 Sep 2015 11:24:32 +0700
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <CAH0njdubznD3HxBNbnyWxWxK1=rf5=2TiEp+QhP25XSBneCXvA@mail.gmail.com>
References: <CAAY=A7-ud3gGQGMKMUL3XBWXE=6Zw+Sz5N27gXbb27Yd_L_Q4g@mail.gmail.com>
 <55F72499.80505@unicaen.fr>
 <CAH0njdubznD3HxBNbnyWxWxK1=rf5=2TiEp+QhP25XSBneCXvA@mail.gmail.com>
Message-ID: <CAPY+ZdTMxSW8zqonzDGBUSNeKVOWO6QaxMMgyehUuR16Cp8yUw@mail.gmail.com>

On Tue, Sep 15, 2015 at 4:45 AM, Brent Yorgey <byorgey at gmail.com> wrote:

> Jerzy, you have been on this list long enough to know that is not an
> appropriate tone to use when responding to people asking questions.  I am
> not disagreeing with the *content* of your message --- indeed, the original
> message sounded a lot like asking the list to solve a homework problem.
> But your response seemed unnecessarily sarcastic and condescending.
>

Wait, Brent, surely you're referring to Jerzy's 2nd email?

The first one to Jorge is a gallicism of lmgtfy.

The second one to Francesco is when he has worked himself up to into a
mousse. (Francesco must've been bemused!)

All very thrilling. And for only powerset. Imagine the crackling energies
before rawer topics.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150915/8e5e9574/attachment.html>

From guillaumh at gmail.com  Tue Sep 15 08:12:06 2015
From: guillaumh at gmail.com (Guillaume Hoffmann)
Date: Tue, 15 Sep 2015 05:12:06 -0300
Subject: [Haskell-cafe] Darcs Hacking Sprint #9 (September 18th-20th,
	Paris)
In-Reply-To: <CADw8UJrRGEfF7Z=91-UzAHpXsn6tcjD+5_jBS-01MBvD8jkQeA@mail.gmail.com>
References: <CADw8UJrRGEfF7Z=91-UzAHpXsn6tcjD+5_jBS-01MBvD8jkQeA@mail.gmail.com>
Message-ID: <CADw8UJqvuXPx6xOKtQne1MgcdHpReuWisOxcWYtx-JNTrRCzxA@mail.gmail.com>

Just a reminder that the next Darcs sprint is *this weekend* from
Friday to Sunday in Paris.

Have a look below for more details!

2015-08-21 15:58 GMT-03:00 Guillaume Hoffmann <guillaumh at gmail.com>:
> Dear Hackers
>
> the next Darcs Sprint that will be in Paris, on September 18-20 at
> IRILL (near Place d'Italie).
>
> Please check out the details at:
>
> http://darcs.net/Sprints/2015-09
>
> Here are three things to know
>
> 1. Everybody is welcome to join us.  We'd love to have you, whatever
>    your Haskell or Darcs hacking experience.  Also, if you've got a
>    wacky idea for the future of version control, or a cool use for the
>    Darcs library, you should join us too :-)
>
> 2. Please let us know if you're attending.  Just add your name to
>    http://wiki.darcs.net/Sprints/2015-09 and you're good to go.
>    You can also send us an email.
>
> 3. We can reimburse travel costs (within reason!).  Let us know if you'd
>    like a reimbursement, and save your receipts.
>
>    Many thanks to everybody who participated in our fundraising drives
>    or who gave money on the side.  Thanks also to the Software Freedom
>    Conservancy for making fundraising and reimbursements so painless!
>    If you can't join us in person, but you'd like to cheer us on,
>    say hello at http://darcs.net/Donations !
>
> see you in one month!
>
> Guillaume

From ab at fmap.me  Tue Sep 15 09:39:51 2015
From: ab at fmap.me (Nikolay Amiantov)
Date: Tue, 15 Sep 2015 12:39:51 +0300
Subject: [Haskell-cafe] Strange problem with inference
In-Reply-To: <55F21916.4010307@fmap.me>
References: <55F21916.4010307@fmap.me>
Message-ID: <55F7E767.90108@fmap.me>

Thank you all for responses! There are always more things to learn ^_^.
I'll also take a look at the paper to understand better what's going on.

On 09/11/2015 02:58 AM, Nikolay Amiantov wrote:
> Hi Cafe,
> 
> I've been playing around with lens and stumbled upon strange GHC
> behaviour. Consider this source (using lens package and GHC 7.10.2):
> 
> {-# LANGUAGE TypeFamilies #-}
> 
> import Control.Lens
> 
> class Test a where
>   type TestT a
>   myiso :: Iso' a (TestT a)
> 
> test1 :: Test a => a -> TestT a
> test1 = view myiso
> 
> test2 :: Test a => TestT a -> a
> test2 = view (from myiso)
> 
> GHC would emit this error:
> 
> /tmp/test.hs:13:9:
>     Could not deduce (Control.Monad.Reader.Class.MonadReader
>                         (TestT a) ((->) (TestT a)))
>       arising from a use of ?view?
>     from the context (Test a)
>       bound by the type signature for test2 :: Test a => TestT a -> a
>       at /tmp/test.hs:12:10-31
>     In the expression: view (from myiso)
>     In an equation for ?test2?: test2 = view (from myiso)
> Failed, modules loaded: none.
> 
> However, `MonadReader r ((->) r)` is defined for any and all `r`!
> Furthermore, `test1` has no problem with this and `view` there uses this
> instance too. The only difference that I see is the presence of a type
> family:
> 
> * `test1` needs `MonadReader a ((->) a)`
> * `test2` needs `MonadReader (TestT a) ((->) (TestT a))`
> 
> , but I don't understand how can this result in a different behavior.
> Notice that this likely may be reproduced somehow without lens -- I've
> spent some time trying to minify this example further but alas to no avail.
> 
> Thanks in advance!
> 

-- 
Nikolay.

From winterkoninkje at gmail.com  Tue Sep 15 11:58:28 2015
From: winterkoninkje at gmail.com (wren romano)
Date: Tue, 15 Sep 2015 07:58:28 -0400
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <55F3EC7B.70103@unicaen.fr>
References: <CANNywiu=bFw_W6OJ_QNz4BCBhMp=bOjGS_qGxV+=CPvA78gL+A@mail.gmail.com>
 <CABUjdS51gWw_rKoyPNmOp=opu4fNk+m_yYoy20qAUjKZzpEXvw@mail.gmail.com>
 <CAJUDvcjMMn4aDuW6riQmRdDiZz6_3rPmt4BcUvnnjQ0w5Q-2qw@mail.gmail.com>
 <1c238a21-0152-430b-981e-19c392ee9cc3@googlegroups.com>
 <55F3EC7B.70103@unicaen.fr>
Message-ID: <CABUjdS5LzipBYoCZ8H=LyEBmML1i1isGT7gzG6+LfrZs0jPeLg@mail.gmail.com>

On Sat, Sep 12, 2015 at 5:12 AM, Jerzy Karczmarczuk
<jerzy.karczmarczuk at unicaen.fr> wrote:
> And whatever people say, e.g., Wren Romano:
>
>> There are far more objects which have
>> addition/multiplication without subtraction than there are objects
>> with addition/subtraction without multiplication.
>
> ... several simple-minded people (myself included)  will find not so useful
> and/or clumsy the introduction of specific structures just to forbid the
> subtraction. Nobody will fight against these purists, it is simply a
> difficult issue.

I can assure you that there are numerous examples that even the most
"simple-minded" programmers are already intimately familiar with; cf.,
<http://winterkoninkje.dreamwidth.org/80410.html>.

People use tropical, arctic, and Viterbi semirings all over the place:
e.g., almost[1] every minimization/maximization problem where there's
some notion of gluing together subproblems. People use bounded
distributed lattices all the time: e.g., most everything in naive set
theory. People use regular languages/regexes all the time. All of
these are semirings, and none of them are rings.

Semirings are perfectly banal everyday things. The only difficulty is
in realizing how ubiquitous they are. This has nothing to do with
being a purist. I want semirings encoded as a type class because ?as a
workaday programmer? I find myself almost daily wanting to
parameterize some algorithm to use a different semiring. All the
structure of linear algebra is far more complicated than what's going
on here. Most programmers ("simple-minded" or otherwise) do not
actually work with linear algebra; but almost every programmer has to
deal with sets, parsing/languages, minimizing/maximizing, not screwing
up array indices by going negative, etc etc.


[1] The salient min/max problems that don't fit that characterization
are the ones where we have two notions of gluing together sub
problems, in which case we generally want an ordered semiring? which
is just a generalization.

-- 
Live well,
~wren

From winterkoninkje at gmail.com  Tue Sep 15 12:27:11 2015
From: winterkoninkje at gmail.com (wren romano)
Date: Tue, 15 Sep 2015 08:27:11 -0400
Subject: [Haskell-cafe] Thoughts about redesigning "Num" type class
In-Reply-To: <55F479DD.8010308@unicaen.fr>
References: <3C3122F5-B2DA-4AAF-9599-A6A33E5FEC17@aatal-apotheke.de>
 <55F44BD2.1080307@unicaen.fr>
 <CAML5wvsJFCYS1j4iivm7qyAFjeQmBW6Zx-qNXOrSGkKNaHNZ9g@mail.gmail.com>
 <55F479DD.8010308@unicaen.fr>
Message-ID: <CABUjdS7Wq6xLJHm+iAq7EycO4L4_n9qhueonXiMCY=PJrgBd7A@mail.gmail.com>

On Sat, Sep 12, 2015 at 3:15 PM, Jerzy Karczmarczuk
<jerzy.karczmarczuk at unicaen.fr> wrote:
> On the other hand, I would like to see where, in what kind of computations,
> the Rig type class would be useful

For a simple example, consider solving a sequence tagging problem with
a hidden Markov model. That is, an HMM is a pair of (1) a "transition
table" which gives the probability of moving from one state to
another, and (2) an "emission/generation/observation table" which
gives the probability of making an observation given that we're in a
particular state. The sequence tagging problem says, for some
particular HMM, if we're given a sequence of observations we want to
learn something about the sequence of states which would've generated
those observations. Of course the question is what exactly is this
"something" we want to learn? Things we could want to learn:

* what is the total (over all state sequences) probability of
generating the observed sequence?
* what is the probability of the most likely state sequence given the
observed sequence?
* what is the most likely state sequence (itself) given the observed sequence?
* what are the top N most likely states sequences...
...

We can implement a single algorithm that answers all of these
questions, the only difference is which semiring the algorithm uses
when doing stuff. For example, to get the total probability we use the
<+,*> semiring. To get the probability of the single most-likely
sequence we use the <max,+> semiring. To get the most-likely sequence
itself we can use the semiring obtained by modifying the <max,+>
semiring to keep track of backpointers. And so on.

More importantly, it's not just that we *can* come up with a single
unified algorithm, it's that this is the natural algorithm we'd come
up with for solving any of these problems individually. All these
problems can be solved by the same algorithm because they all have the
same structure as a dynamic program; the only difference is what the
values are that we store in the cells of the DP table and how we
combine those values.

Of course, there's nothing important about the fact that we're dealing
with HMMs nor probabilities. We can do the same sort of thing for any
notion of a first-order transition system; e.g., parsing with CFGs.


> (and how to squeeze infinity into it).

Whether your semiring has infinity or not doesn't matter (unless
infinity just so happens to be serving the role of the zero or unit).
So, no squeezing in to be done.

(If you're interested in *-semirings, then having infinities might
matter; but for that, see the blog post I mentioned previously.)

-- 
Live well,
~wren

From olf at aatal-apotheke.de  Tue Sep 15 13:02:48 2015
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Tue, 15 Sep 2015 15:02:48 +0200
Subject: [Haskell-cafe] Powerset of a set
Message-ID: <74938ABA-8089-4961-8500-99C6BF903205@aatal-apotheke.de>

This was one of the most woundrous moments I ever had with reading a Haskell library: If lists are used to represent finite sets (hence disregarding order and multiplicity of elements), then 

Control.Monad.filterM (const [False,True]) :: [a] -> [[a]]

computes the powerset. Exercise for Jorge: Read the source code of filterM [*], understand what this function is doing, and why this indeed computes (a representation of) the powerset. 

Cheers,
Olaf

[*] http://hackage.haskell.org/package/base-4.8.1.0/docs/src/Control.Monad.html#filterM

From kyle.marek.spartz at gmail.com  Tue Sep 15 14:14:08 2015
From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz)
Date: Tue, 15 Sep 2015 09:14:08 -0500
Subject: [Haskell-cafe] Haskell related search engines in the Opera
	browser
In-Reply-To: <op.x4y5sln5pz0j5l@alquantor>
References: <op.x4y5sln5pz0j5l@alquantor>
Message-ID: <2fcp3sy4g7ydlb.fsf@gmail.com>

Relatedly, if you use DuckDuckGo as your search engine, there's a number
of "Bangs" you can use:

!hoogle (a -> b) -> a -> b
!hackage defaultTimeLocale
!hayoo defaultTimeLocale
!haskellwiki Applications and libraries

This way you only need to change one setting (use DuckDuckGo) and you get all
these, and thousands more:

https://duckduckgo.com/bang

Henk-Jan van Tuyl writes:

> L.S.,
>
> It is easy to define the search facility of the Haskell wiki as a search
> engine in the Opera browser. Press alt-p to get to the preferences panel
> (details differ per Opera version) and define the following parameters for
> the new search engine:
>    Name    HaskellWiki
>    Keyword hw
>    Address https://wiki.haskell.org/Special:Search?search=%s
>
> Now you can enter, for example,
>    hw wxHaskell
> on the URL bar, to get to the wxHaskell page on the Haskell wiki.
> Another option is to double click a word on a web page, right click on the
> word and select Search with -> HaskellWiki.
>
> Similarly, you can search with Hoogle:
>    Name    Hoogle
>    Keyword h
>    Address http://www.stackage.org/lts-2.22/hoogle?q=%s
>
> Hackage:
>    Name    HackageDB
>    Keyword hd
>    Address https://hackage.haskell.org/package/%s
>
> Hayoo:
>    Name    Hayoo
>    Keyword hay
>    Address http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=%s
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Folding at home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming

--
Kyle Marek-Spartz

From amindfv at gmail.com  Tue Sep 15 15:01:38 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Tue, 15 Sep 2015 11:01:38 -0400
Subject: [Haskell-cafe] Haskell related search engines in the Opera
	browser
In-Reply-To: <2fcp3sy4g7ydlb.fsf@gmail.com>
References: <op.x4y5sln5pz0j5l@alquantor> <2fcp3sy4g7ydlb.fsf@gmail.com>
Message-ID: <E268E303-E2E8-49CC-A182-23D7EA380808@gmail.com>

Actually, even just "!h" searches hoogle in ddg!

Tom


El Sep 15, 2015, a las 10:14, Kyle Marek-Spartz <kyle.marek.spartz at gmail.com> escribi?:

> Relatedly, if you use DuckDuckGo as your search engine, there's a number
> of "Bangs" you can use:
> 
> !hoogle (a -> b) -> a -> b
> !hackage defaultTimeLocale
> !hayoo defaultTimeLocale
> !haskellwiki Applications and libraries
> 
> This way you only need to change one setting (use DuckDuckGo) and you get all
> these, and thousands more:
> 
> https://duckduckgo.com/bang
> 
> Henk-Jan van Tuyl writes:
> 
>> L.S.,
>> 
>> It is easy to define the search facility of the Haskell wiki as a search
>> engine in the Opera browser. Press alt-p to get to the preferences panel
>> (details differ per Opera version) and define the following parameters for
>> the new search engine:
>>   Name    HaskellWiki
>>   Keyword hw
>>   Address https://wiki.haskell.org/Special:Search?search=%s
>> 
>> Now you can enter, for example,
>>   hw wxHaskell
>> on the URL bar, to get to the wxHaskell page on the Haskell wiki.
>> Another option is to double click a word on a web page, right click on the
>> word and select Search with -> HaskellWiki.
>> 
>> Similarly, you can search with Hoogle:
>>   Name    Hoogle
>>   Keyword h
>>   Address http://www.stackage.org/lts-2.22/hoogle?q=%s
>> 
>> Hackage:
>>   Name    HackageDB
>>   Keyword hd
>>   Address https://hackage.haskell.org/package/%s
>> 
>> Hayoo:
>>   Name    Hayoo
>>   Keyword hay
>>   Address http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=%s
>> 
>> Regards,
>> Henk-Jan van Tuyl
>> 
>> 
>> --
>> Folding at home
>> What if you could share your unused computer power to help find a cure? In
>> just 5 minutes you can join the world's biggest networked computer and get
>> us closer sooner. Watch the video.
>> http://folding.stanford.edu/
>> 
>> 
>> http://Van.Tuyl.eu/
>> http://members.chello.nl/hjgtuyl/tourdemonad.html
>> Haskell programming
> 
> --
> Kyle Marek-Spartz
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From bneijt at gmail.com  Tue Sep 15 16:42:16 2015
From: bneijt at gmail.com (Bram Neijt)
Date: Tue, 15 Sep 2015 18:42:16 +0200
Subject: [Haskell-cafe] Converting EpochTime to Integer
Message-ID: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>

Dear Haskell cafe,

I want to convert form

mtime :: System.Posix.Types.EpochTime

to something aeson can eat without having to define an instance. I
choose Integer.

My current solution[1] is just using (read . show). I know, ugly, but
the only thing I could get going.

What is the proper way to convert System.Posix.Types.EpochTime to
Integer or something else aeson will automatically convert without
making a ToJSON instance?

As a beginner I wonder: is there a general way to go about finding
conversion paths between types?


Greetings,

Bram Neijt

[1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21

From chpatrick at gmail.com  Tue Sep 15 16:46:47 2015
From: chpatrick at gmail.com (Patrick Chilton)
Date: Tue, 15 Sep 2015 17:46:47 +0100
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
Message-ID: <CAKsM4rUcDQjQy0jSTACTE9hQEJTomf-q+_FPEaWcx7yyW5wOEQ@mail.gmail.com>

type EpochTime = CTime
newtype CTime = CTime Int64

You can just pattern match.

On Tue, Sep 15, 2015 at 5:42 PM, Bram Neijt <bneijt at gmail.com> wrote:

> Dear Haskell cafe,
>
> I want to convert form
>
> mtime :: System.Posix.Types.EpochTime
>
> to something aeson can eat without having to define an instance. I
> choose Integer.
>
> My current solution[1] is just using (read . show). I know, ugly, but
> the only thing I could get going.
>
> What is the proper way to convert System.Posix.Types.EpochTime to
> Integer or something else aeson will automatically convert without
> making a ToJSON instance?
>
> As a beginner I wonder: is there a general way to go about finding
> conversion paths between types?
>
>
> Greetings,
>
> Bram Neijt
>
> [1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150915/d43fd243/attachment.html>

From kane at kane.cx  Tue Sep 15 16:48:46 2015
From: kane at kane.cx (David Kraeutmann)
Date: Tue, 15 Sep 2015 18:48:46 +0200
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
Message-ID: <55F84BEE.2040709@kane.cx>

EpochTime is an instance of Integral. You can just use toInteger ::
Integral a => a -> Integer.
On 9/15/2015 6:42 PM, Bram Neijt wrote:
> Dear Haskell cafe,
> 
> I want to convert form
> 
> mtime :: System.Posix.Types.EpochTime
> 
> to something aeson can eat without having to define an instance. I
> choose Integer.
> 
> My current solution[1] is just using (read . show). I know, ugly, but
> the only thing I could get going.
> 
> What is the proper way to convert System.Posix.Types.EpochTime to
> Integer or something else aeson will automatically convert without
> making a ToJSON instance?
> 
> As a beginner I wonder: is there a general way to go about finding
> conversion paths between types?
> 
> 
> Greetings,
> 
> Bram Neijt
> 
> [1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150915/aade360d/attachment.bin>

From jerzy.karczmarczuk at unicaen.fr  Tue Sep 15 18:02:03 2015
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 15 Sep 2015 20:02:03 +0200
Subject: [Haskell-cafe] Powerset of a set
In-Reply-To: <74938ABA-8089-4961-8500-99C6BF903205@aatal-apotheke.de>
References: <74938ABA-8089-4961-8500-99C6BF903205@aatal-apotheke.de>
Message-ID: <55F85D1B.20400@unicaen.fr>

Olaf Klinke :
> Control.Monad.filterM (const [False,True]) :: [a] -> [[a]]
>
> computes the powerset. Exercise for Jorge: Read the source code of filterM [*], understand what this function is doing, and why this indeed computes (a representation of) the powerset.
This is very nice and compact. But Olaf begins with:
"This was one of the most woundrous moments I ever had with reading a 
Haskell library"

For me it became once a source of pain... After having taught Haskell 
for some years, I fell into the overgeneralization trap, trying to 
convince students that the most generic procedures are Good. Final calls 
are compact, boilerplate reduced, the patterns used may be inspiring and 
reused, etc.

But for the beginners, needing a clue on how a - say - non-deterministic 
algorithm works, it was a failure. It *could* work, if the students had 
time and patience to concentrate on those universalities.
No, an advice: "read the library sources" is for people who have really 
some free time, or want to specialize. Never for beginners, whose first 
aim is to solve THE problem.

Finally, I began with a crash course of Prolog, with the generation of 
ANY subset: either you choose an element or not, and that's all.

sset([],[]).
sset([X|Q],R):-(R=T;R=[X|T]),sset(Q,T).

and we reconstructed the List Monad from it. And it worked, although it 
was not so ambitious. Here it is, if somebody doesn't want it, don't 
read. But no comprehensions inside, so, the needs of Jorge M. are not 
satisfied.

sset [] = return []
sset (x:q) =
  do
   t <- sset q; return t ++ return (x:t)

((( or
sset (x:q) = sset q >>= (\t -> return t ++ return (x:t))
)))

This is not very ambitious, quite plain (and not optimized). But an 
ambitious beginner should be able to understand what is going on ; no 
"(const [False,True])" inside, which is obviously artificial.
We tried to concentrate on the immediate solution, and only after 
treating permutations, partitions of an integer, and several other 
examples, we could generalize...

Jerzy


From mwm at mired.org  Tue Sep 15 18:23:57 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 15 Sep 2015 18:23:57 +0000
Subject: [Haskell-cafe] Sound advice
Message-ID: <CAD=7U2CDGuUE4fecYry5tz894cQwh1+MkVnH2NLwjpWRXezC8A@mail.gmail.com>

I'm looking for advice on generating sounds from a desktop app. I'm
perfectly happy if it doesn't have a GUI, but runs from the command line.

The desire is to take a config file for an embedded device that encodes
tunes it plays back and play them on the desktop. The data could be
represented as:

type Note = Integer
type Duration = Integer
data Tone = Tone Note Duration
newtype Tune = Tune [Tone]

[N.B. - I don't necessarily plan on using the above, I just wanted to
illustrate the types.

Now I just need to play back the resulting tune.

Looking through hackage and hoogle find a number of sound libraries, but
they either seem to be targeted at manipulating audio files and the data
therein, or dealing with midi events and associated devices. I suspect that
at least one of them can do what I want, but before I start delving into
one I'd like to know that it can do this with minimal extra code and pain.

So, anyone want to suggest a library for this task?

Thanks,
<mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150915/17741872/attachment.html>

From allbery.b at gmail.com  Tue Sep 15 18:36:19 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 15 Sep 2015 14:36:19 -0400
Subject: [Haskell-cafe] Sound advice
In-Reply-To: <CAD=7U2CDGuUE4fecYry5tz894cQwh1+MkVnH2NLwjpWRXezC8A@mail.gmail.com>
References: <CAD=7U2CDGuUE4fecYry5tz894cQwh1+MkVnH2NLwjpWRXezC8A@mail.gmail.com>
Message-ID: <CAKFCL4WCm8HK2rPprkAvJWU5MrkWs6_2Hsdzqub5UnaATPP4uA@mail.gmail.com>

On Tue, Sep 15, 2015 at 2:23 PM, Mike Meyer <mwm at mired.org> wrote:

> I'm looking for advice on generating sounds from a desktop app. I'm
> perfectly happy if it doesn't have a GUI, but runs from the command line.
>

http://hackage.haskell.org/package/csound-expression was recently updated
(and announced in here).

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150915/29733696/attachment.html>

From amindfv at gmail.com  Tue Sep 15 23:32:21 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Tue, 15 Sep 2015 19:32:21 -0400
Subject: [Haskell-cafe] Sound advice
In-Reply-To: <CAKFCL4WCm8HK2rPprkAvJWU5MrkWs6_2Hsdzqub5UnaATPP4uA@mail.gmail.com>
References: <CAD=7U2CDGuUE4fecYry5tz894cQwh1+MkVnH2NLwjpWRXezC8A@mail.gmail.com>
 <CAKFCL4WCm8HK2rPprkAvJWU5MrkWs6_2Hsdzqub5UnaATPP4uA@mail.gmail.com>
Message-ID: <973EF3C2-CB28-4B2F-881A-F36863EE12B1@gmail.com>

Or Supercollider! Which you can interact with with my "vivid" libarary or the "hsc3" library (both on hackage).

In vivid 0.1 (0.2 is coming soon but not out yet), you'd do something like 

playTune :: Tune -> IO ()
playTune (Tune ts) = mapM_ playTone ts

playTone :: Tone -> IO ()
playTone (Tone note dur) = do
   s <- play $ do
      s0 <- sinOsc (Freq $ midiCPS note)
      out 0 [s0, s0]
   sleep dur
   free s

(There may be a typo here; writing it on my phone)

I'm happy to answer any questions, too.

tom



El Sep 15, 2015, a las 14:36, Brandon Allbery <allbery.b at gmail.com> escribi?:

> On Tue, Sep 15, 2015 at 2:23 PM, Mike Meyer <mwm at mired.org> wrote:
>> I'm looking for advice on generating sounds from a desktop app. I'm perfectly happy if it doesn't have a GUI, but runs from the command line.
> 
> http://hackage.haskell.org/package/csound-expression was recently updated (and announced in here).
> 
> -- 
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150915/8d6b067d/attachment.html>

From dxld at darkboxed.org  Wed Sep 16 05:47:03 2015
From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=)
Date: Wed, 16 Sep 2015 07:47:03 +0200
Subject: [Haskell-cafe] ANN ghc-mod-5.4.0.0, now with Stack support!
Message-ID: <20150916054703.GA4992@grml>

I'm pleased to announce the release of ghc-mod 5.4.0.0!

What's new?
===========

* Stack support

  After countless requests ghc-mod now finally has first class Stack
  support. This should mostly Just-Work^TM there is one caveat though if
  `dist/setup-config` exists in a Cabal-project directory ghc-mod will continue
  using cabal-install instead of Stack so if you want to use Stack instead
  simply remove that file or the whole directory. You also need at least Stack
  version 0.1.4.0 for this to work.

* Support for unsaved files

  Nikolay Yakimov (@lierdakil) has contributed support for remapping files in a
  project to temporary files so that the frontend can use these to communicate
  unsaved file contents to ghc-mod. This is currently supported by Atom's
  ide-haskell and ghc-mod own Emacs frontend. If you're using a different
  frontend you should probably nudge the maintainer to get this supported.

* Massive slowdown has been fixed

  A bug causing recompilation checking to be skipped, introduced in v5.3.0.0,
  has been fixed and ghc-mod should be as responsive as `:reload` in ghci again.

* Fixed `Cannot add module to context: not interpreted`

  When compilation output from a `cabal build` run were present in `dist/`
  ghc-mod would in certain cases throw this error. This bug was introduced in
  v5.3.0.0 and has now been fixed.


What is ghc-mod?
================

ghc-mod is both a backend program for enhancing editors and other kinds of
development environments with support for Haskell and a library for abstracting
the black magic incantations required to use the GHC API in various
environments, especially Cabal projects. The library is used by ambitious
projects like HaRe[1] and mote[2].


Getting ghc-mod
===============

GitHub: https://github.com/kazu-yamamoto/ghc-mod
Hackage: http://hackage.haskell.org/package/ghc-mod

Editor frontends:

  - Emacs (native):
      https://github.com/kazu-yamamoto/ghc-mod
      https://github.com/iquiw/company-ghc
  - Vim:
      https://github.com/eagletmt/ghcmod-vim
      https://github.com/eagletmt/neco-ghc
  - Atom:
      https://github.com/atom-haskell/ide-haskell
      https://github.com/andyfriesen/Helium

Known issues
============

ghc-mod's `case`, `sig` and `refine` commands still do not work properly with
GHC 7.10 (See https://github.com/kazu-yamamoto/ghc-mod/issues/438). Unless
someone volunteers to fix this issue I will work towards repacing the features
using mote[2] instead as the current code is, from my point of view,
unmaintainable.

If you do notice any other problems please report them:
https://github.com/kazu-yamamoto/ghc-mod/issues

----
[1]: https://github.com/alanz/HaRe
[2]: https://github.com/imeckler/mote
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/63a0c72d/attachment.sig>

From anton.kholomiov at gmail.com  Wed Sep 16 07:05:35 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Wed, 16 Sep 2015 10:05:35 +0300
Subject: [Haskell-cafe] [haskell art] the library of beautiful
 instruments implemented in haskell / csound
In-Reply-To: <877fnrzee8.fsf@cam.ac.uk>
References: <CADDxdqMLh+VzkDmGWRuiRbX7AKM_GtCQfg5bkNw4Yx5TNCHhog@mail.gmail.com>
 <877fnrzee8.fsf@cam.ac.uk>
Message-ID: <CADDxdqPinSq4VeR6UpyQwk_VW4f3kROkVQ4Wo+E83yA-o9jAdA@mail.gmail.com>

Alas there is no CsdSco typeclass anymore.
The original idea was to implement score type with
the most basic type and give the user a chance to write converters
and use score playing functionality by the class CsdSco.
But I've noticed that this approach was preventing me from using
advanced score structures (they are implemented in the separate package).
And type signatures become scary for the novice.
So I've settled down the type. It's like choosing between Prelude.List
ListLike.List. I've decided to pick the simplest one.

You can write your own converter to the `Sco` type.

````
type Sco a = Track
<http://hackage.haskell.org/package/temporal-media-0.6.0/docs/Temporal-Media.html#t:Track>
 D
<http://hackage.haskell.org/package/csound-expression-4.8.2/docs/Csound-Types.html#t:D>
 a
```

The `Track` comes from temporal-media package.
It's very easy to construct it from list of events.
One possible solution:

```
type Note = (Double, Double, a)

fromEvents :: [Note] -> Sco a
fromEvents = har . fmap f
     where f (start, duration, a) = del (double start) $ str (double
duration) $ temp a
```

Notice the need for converting to csound doubles (`D`s). The `har` is
parallel composition.
`del` is for delaying nd `str` is for stretching in time domain. `temp`
creates an event
that lasts for one seconds and starts right away.
I don't know your type, but I think it can be rendered to a list of notes.

Then you can plug the converter to the functions: `sco` or `atSco` (used
for patches).


Cheers,
Anton

2015-09-15 22:11 GMT+03:00 Edward Lilley <ejlilley at gmail.com>:

> Hi
>
> The most useful part of this (for me) is the ability to play midi-style
> instruments at arbitrary frequencies, so this looks great!
>
> To that end, I'm looking for the definition of the 'CsdSco' typeclass,
> as I want to write my own instance. It seems to be referenced in the
> csound-expression documentation, and once in a code comment, but is
> otherwise absent from the source. Indeed, installing temporal-csound
> from hackage fails with the error
>
> src/Csound.hs:135:10:
>     Not in scope: type constructor or class ?CsdSco?
>
> Where do I find it?
>
> thanks,
> Edward
>
> Anton Kholomiov <anton.kholomiov at gmail.com> writes:
>
> > Status update for my haskell synth csound-expression. The main point is
> > presence of many cool instruments. They are implemented in the package
> > csound-catalog. All packages are compiled with GHC-7.10 So the hackage
> > fails to build them and unfortunately docs a broken too. But you can look
> > at the source code of the module Csound.Patch to now  the names of the
> > instruments. The usage is pretty straightforward. It's described here:
> >
> >
> https://github.com/spell-music/csound-expression/blob/master/tutorial/chapters/Patches.md
> >
> > There is an mp3 file to listen to the instruments.
> http://ge.tt/1jNETqN2/v/0
> >
> > *The 4.8.3 is out! New features:*
> >
> > This is a very important release to me. It tries to solve the problem
> > present in the most open source music-production libraries. It's often
> the
> > pack of beautiful sounds/timbres is missing. User is presented with many
> > audio primitives but no timbres are present to show the real power of the
> > framework. This release solves this problem. See the friend package
> > csound-catalog on Hackage. It defines 200+ beautiful instruments ready to
> > be used.
> >
> > The csound-expression defines a new type called Patch for description of
> an
> > instrument with a chain of effects. It's good place to start the journey
> to
> > the world of music production.
> >
> > There are new functions for synchronized reaction on events. The
> triggering
> > of events can be synchronized with given BPM.
> >
> > The library is updated for GHC-7.10!
> >
> >
> > github repo: https://github.com/spell-music/csound-expression
> >
> > hackage: http://hackage.haskell.org/package/csound-expression
> >
> >
> > Cheers!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/64c2d960/attachment.html>

From anton.kholomiov at gmail.com  Wed Sep 16 07:12:58 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Wed, 16 Sep 2015 10:12:58 +0300
Subject: [Haskell-cafe] Sound advice
In-Reply-To: <CAD=7U2CDGuUE4fecYry5tz894cQwh1+MkVnH2NLwjpWRXezC8A@mail.gmail.com>
References: <CAD=7U2CDGuUE4fecYry5tz894cQwh1+MkVnH2NLwjpWRXezC8A@mail.gmail.com>
Message-ID: <CADDxdqOpFGv8eqfzBRbkd7Q8R0s2GHjzzOe47j=kCo3m0qjcKQ@mail.gmail.com>

If you decide to use my lib for desktop (csound-expression).
The examples can lead you to think that the audio
is generated with Haskell which is not so.
It requires the installation of csound command line utility.
The Haskell just generates the code for csound.

2015-09-15 21:23 GMT+03:00 Mike Meyer <mwm at mired.org>:

> I'm looking for advice on generating sounds from a desktop app. I'm
> perfectly happy if it doesn't have a GUI, but runs from the command line.
>
> The desire is to take a config file for an embedded device that encodes
> tunes it plays back and play them on the desktop. The data could be
> represented as:
>
> type Note = Integer
> type Duration = Integer
> data Tone = Tone Note Duration
> newtype Tune = Tune [Tone]
>
> [N.B. - I don't necessarily plan on using the above, I just wanted to
> illustrate the types.
>
> Now I just need to play back the resulting tune.
>
> Looking through hackage and hoogle find a number of sound libraries, but
> they either seem to be targeted at manipulating audio files and the data
> therein, or dealing with midi events and associated devices. I suspect that
> at least one of them can do what I want, but before I start delving into
> one I'd like to know that it can do this with minimal extra code and pain.
>
> So, anyone want to suggest a library for this task?
>
> Thanks,
> <mike
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/4060610b/attachment.html>

From bneijt at gmail.com  Wed Sep 16 11:19:02 2015
From: bneijt at gmail.com (Bram Neijt)
Date: Wed, 16 Sep 2015 13:19:02 +0200
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <55F84BEE.2040709@kane.cx>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
Message-ID: <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>

I'm sorry, but as a newby I can't seem to get it to work.

If I use
    return (mtime :: Integer)
I get
    src/Main.hs:21:13:
        Couldn't match type ?Foreign.C.Types.CTime? with ?Integer?
        Expected type: Integer
          Actual type: System.Posix.Types.EpochTime
        In the first argument of ?return?, namely ?(mtime :: Integer)?
        In a stmt of a 'do' block: return (mtime :: Integer)

If I use
    return (toInteger mtime)
I get
    src/Main.hs:21:13:
        No instance for (Integral System.Posix.Types.EpochTime)
          arising from a use of ?toInteger?
        In the first argument of ?return?, namely ?(toInteger mtime)?
        In a stmt of a 'do' block: return (toInteger mtime)
        In the expression:
          do { status <- getFileStatus filepath;
               let mtime = modificationTime status;
               return (toInteger mtime) }

What am I doing wrong here? How would I pattern match to convert the type?

Greetings,

Bram

PS Code is still
https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
Versions
cabal-install version 1.22.2.0
using version 1.22.2.0 of the Cabal library
The Glorious Glasgow Haskell Compilation System, version 7.10.1





On Tue, Sep 15, 2015 at 6:48 PM, David Kraeutmann <kane at kane.cx> wrote:
> EpochTime is an instance of Integral. You can just use toInteger ::
> Integral a => a -> Integer.
> On 9/15/2015 6:42 PM, Bram Neijt wrote:
>> Dear Haskell cafe,
>>
>> I want to convert form
>>
>> mtime :: System.Posix.Types.EpochTime
>>
>> to something aeson can eat without having to define an instance. I
>> choose Integer.
>>
>> My current solution[1] is just using (read . show). I know, ugly, but
>> the only thing I could get going.
>>
>> What is the proper way to convert System.Posix.Types.EpochTime to
>> Integer or something else aeson will automatically convert without
>> making a ToJSON instance?
>>
>> As a beginner I wonder: is there a general way to go about finding
>> conversion paths between types?
>>
>>
>> Greetings,
>>
>> Bram Neijt
>>
>> [1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From hesselink at gmail.com  Wed Sep 16 11:42:54 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 16 Sep 2015 13:42:54 +0200
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
 <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
Message-ID: <CAPeieQFGXxsBhO1WVWnodYiq37BE7R2cn33VrH_yYYv8o-UU0g@mail.gmail.com>

Hi Bram,

You can do

    case mtime of
      CTime t -> fromIntegral t

Here `mtime :: EpochTime`, `t :: Int64` and the result is any `Num`
you want, including `Integer`.

CTime doesn't have an Integral instance itself, probably because
division on times doesn't make sense. That's why you can't use
`fromIntegral` directly.

Regards,

Erik

On 16 September 2015 at 13:19, Bram Neijt <bneijt at gmail.com> wrote:
> I'm sorry, but as a newby I can't seem to get it to work.
>
> If I use
>     return (mtime :: Integer)
> I get
>     src/Main.hs:21:13:
>         Couldn't match type ?Foreign.C.Types.CTime? with ?Integer?
>         Expected type: Integer
>           Actual type: System.Posix.Types.EpochTime
>         In the first argument of ?return?, namely ?(mtime :: Integer)?
>         In a stmt of a 'do' block: return (mtime :: Integer)
>
> If I use
>     return (toInteger mtime)
> I get
>     src/Main.hs:21:13:
>         No instance for (Integral System.Posix.Types.EpochTime)
>           arising from a use of ?toInteger?
>         In the first argument of ?return?, namely ?(toInteger mtime)?
>         In a stmt of a 'do' block: return (toInteger mtime)
>         In the expression:
>           do { status <- getFileStatus filepath;
>                let mtime = modificationTime status;
>                return (toInteger mtime) }
>
> What am I doing wrong here? How would I pattern match to convert the type?
>
> Greetings,
>
> Bram
>
> PS Code is still
> https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
> Versions
> cabal-install version 1.22.2.0
> using version 1.22.2.0 of the Cabal library
> The Glorious Glasgow Haskell Compilation System, version 7.10.1
>
>
>
>
>
> On Tue, Sep 15, 2015 at 6:48 PM, David Kraeutmann <kane at kane.cx> wrote:
>> EpochTime is an instance of Integral. You can just use toInteger ::
>> Integral a => a -> Integer.
>> On 9/15/2015 6:42 PM, Bram Neijt wrote:
>>> Dear Haskell cafe,
>>>
>>> I want to convert form
>>>
>>> mtime :: System.Posix.Types.EpochTime
>>>
>>> to something aeson can eat without having to define an instance. I
>>> choose Integer.
>>>
>>> My current solution[1] is just using (read . show). I know, ugly, but
>>> the only thing I could get going.
>>>
>>> What is the proper way to convert System.Posix.Types.EpochTime to
>>> Integer or something else aeson will automatically convert without
>>> making a ToJSON instance?
>>>
>>> As a beginner I wonder: is there a general way to go about finding
>>> conversion paths between types?
>>>
>>>
>>> Greetings,
>>>
>>> Bram Neijt
>>>
>>> [1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From allbery.b at gmail.com  Wed Sep 16 13:04:21 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 16 Sep 2015 09:04:21 -0400
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
 <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
Message-ID: <CAKFCL4Ugyc1PpV4U42Oky9Pd8Zmv4-ELDtPePkbwDTQPaExNeQ@mail.gmail.com>

On Wed, Sep 16, 2015 at 7:19 AM, Bram Neijt <bneijt at gmail.com> wrote:

> If I use
>     return (toInteger mtime)
> I get
>     src/Main.hs:21:13:
>         No instance for (Integral System.Posix.Types.EpochTime)
>

I had been wondering about the claim that it had an Integral instance,.. it
has Num but not Integral.

It *does* have an Enum instance, so fromEnum shoiuld work.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/2f3537f0/attachment.html>

From chpatrick at gmail.com  Wed Sep 16 13:30:41 2015
From: chpatrick at gmail.com (Patrick Chilton)
Date: Wed, 16 Sep 2015 14:30:41 +0100
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
 <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
Message-ID: <CAKsM4rX8_=+YKf_09yLdTPw-iK=JZWCWdbOpzP2FPDqDE+DLxA@mail.gmail.com>

There's no need to go to Integer, just use this:

epochToJSON :: EpochTime -> Value
epochToJSON (CTime t) = toJSON t

On Wed, Sep 16, 2015 at 12:19 PM, Bram Neijt <bneijt at gmail.com> wrote:

> I'm sorry, but as a newby I can't seem to get it to work.
>
> If I use
>     return (mtime :: Integer)
> I get
>     src/Main.hs:21:13:
>         Couldn't match type ?Foreign.C.Types.CTime? with ?Integer?
>         Expected type: Integer
>           Actual type: System.Posix.Types.EpochTime
>         In the first argument of ?return?, namely ?(mtime :: Integer)?
>         In a stmt of a 'do' block: return (mtime :: Integer)
>
> If I use
>     return (toInteger mtime)
> I get
>     src/Main.hs:21:13:
>         No instance for (Integral System.Posix.Types.EpochTime)
>           arising from a use of ?toInteger?
>         In the first argument of ?return?, namely ?(toInteger mtime)?
>         In a stmt of a 'do' block: return (toInteger mtime)
>         In the expression:
>           do { status <- getFileStatus filepath;
>                let mtime = modificationTime status;
>                return (toInteger mtime) }
>
> What am I doing wrong here? How would I pattern match to convert the type?
>
> Greetings,
>
> Bram
>
> PS Code is still
> https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
> Versions
> cabal-install version 1.22.2.0
> using version 1.22.2.0 of the Cabal library
> The Glorious Glasgow Haskell Compilation System, version 7.10.1
>
>
>
>
>
> On Tue, Sep 15, 2015 at 6:48 PM, David Kraeutmann <kane at kane.cx> wrote:
> > EpochTime is an instance of Integral. You can just use toInteger ::
> > Integral a => a -> Integer.
> > On 9/15/2015 6:42 PM, Bram Neijt wrote:
> >> Dear Haskell cafe,
> >>
> >> I want to convert form
> >>
> >> mtime :: System.Posix.Types.EpochTime
> >>
> >> to something aeson can eat without having to define an instance. I
> >> choose Integer.
> >>
> >> My current solution[1] is just using (read . show). I know, ugly, but
> >> the only thing I could get going.
> >>
> >> What is the proper way to convert System.Posix.Types.EpochTime to
> >> Integer or something else aeson will automatically convert without
> >> making a ToJSON instance?
> >>
> >> As a beginner I wonder: is there a general way to go about finding
> >> conversion paths between types?
> >>
> >>
> >> Greetings,
> >>
> >> Bram Neijt
> >>
> >> [1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/c38780a2/attachment.html>

From chpatrick at gmail.com  Wed Sep 16 13:34:00 2015
From: chpatrick at gmail.com (Patrick Chilton)
Date: Wed, 16 Sep 2015 14:34:00 +0100
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <CAKsM4rX8_=+YKf_09yLdTPw-iK=JZWCWdbOpzP2FPDqDE+DLxA@mail.gmail.com>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
 <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
 <CAKsM4rX8_=+YKf_09yLdTPw-iK=JZWCWdbOpzP2FPDqDE+DLxA@mail.gmail.com>
Message-ID: <CAKsM4rXoWeZJtverUGH4YqEJ6TkfziDtiC_AHMzuzsNVw=orWQ@mail.gmail.com>

To elaborate, EpochTime is just a type synonym for CTime. CTime has a
constructor CTime Int64, so you can pattern match on it to get the Int64
inside. Int64 has a ToJSON instance, so you can run toJSON on it to get a
Value.

On Wed, Sep 16, 2015 at 2:30 PM, Patrick Chilton <chpatrick at gmail.com>
wrote:

> There's no need to go to Integer, just use this:
>
> epochToJSON :: EpochTime -> Value
> epochToJSON (CTime t) = toJSON t
>
> On Wed, Sep 16, 2015 at 12:19 PM, Bram Neijt <bneijt at gmail.com> wrote:
>
>> I'm sorry, but as a newby I can't seem to get it to work.
>>
>> If I use
>>     return (mtime :: Integer)
>> I get
>>     src/Main.hs:21:13:
>>         Couldn't match type ?Foreign.C.Types.CTime? with ?Integer?
>>         Expected type: Integer
>>           Actual type: System.Posix.Types.EpochTime
>>         In the first argument of ?return?, namely ?(mtime :: Integer)?
>>         In a stmt of a 'do' block: return (mtime :: Integer)
>>
>> If I use
>>     return (toInteger mtime)
>> I get
>>     src/Main.hs:21:13:
>>         No instance for (Integral System.Posix.Types.EpochTime)
>>           arising from a use of ?toInteger?
>>         In the first argument of ?return?, namely ?(toInteger mtime)?
>>         In a stmt of a 'do' block: return (toInteger mtime)
>>         In the expression:
>>           do { status <- getFileStatus filepath;
>>                let mtime = modificationTime status;
>>                return (toInteger mtime) }
>>
>> What am I doing wrong here? How would I pattern match to convert the type?
>>
>> Greetings,
>>
>> Bram
>>
>> PS Code is still
>> https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
>> Versions
>> cabal-install version 1.22.2.0
>> using version 1.22.2.0 of the Cabal library
>> The Glorious Glasgow Haskell Compilation System, version 7.10.1
>>
>>
>>
>>
>>
>> On Tue, Sep 15, 2015 at 6:48 PM, David Kraeutmann <kane at kane.cx> wrote:
>> > EpochTime is an instance of Integral. You can just use toInteger ::
>> > Integral a => a -> Integer.
>> > On 9/15/2015 6:42 PM, Bram Neijt wrote:
>> >> Dear Haskell cafe,
>> >>
>> >> I want to convert form
>> >>
>> >> mtime :: System.Posix.Types.EpochTime
>> >>
>> >> to something aeson can eat without having to define an instance. I
>> >> choose Integer.
>> >>
>> >> My current solution[1] is just using (read . show). I know, ugly, but
>> >> the only thing I could get going.
>> >>
>> >> What is the proper way to convert System.Posix.Types.EpochTime to
>> >> Integer or something else aeson will automatically convert without
>> >> making a ToJSON instance?
>> >>
>> >> As a beginner I wonder: is there a general way to go about finding
>> >> conversion paths between types?
>> >>
>> >>
>> >> Greetings,
>> >>
>> >> Bram Neijt
>> >>
>> >> [1]
>> https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
>> >> _______________________________________________
>> >> Haskell-Cafe mailing list
>> >> Haskell-Cafe at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> >>
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> >
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/45e4720a/attachment.html>

From roma at ro-che.info  Wed Sep 16 13:54:54 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Wed, 16 Sep 2015 16:54:54 +0300
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <CAKFCL4Ugyc1PpV4U42Oky9Pd8Zmv4-ELDtPePkbwDTQPaExNeQ@mail.gmail.com>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
 <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
 <CAKFCL4Ugyc1PpV4U42Oky9Pd8Zmv4-ELDtPePkbwDTQPaExNeQ@mail.gmail.com>
Message-ID: <55F974AE.8000206@ro-che.info>

On 16/09/15 16:04, Brandon Allbery wrote:
> On Wed, Sep 16, 2015 at 7:19 AM, Bram Neijt <bneijt at gmail.com
> <mailto:bneijt at gmail.com>> wrote:
> 
>     If I use
>         return (toInteger mtime)
>     I get
>         src/Main.hs:21:13:
>             No instance for (Integral System.Posix.Types.EpochTime)
> 
> 
> I had been wondering about the claim that it had an Integral instance,..
> it has Num but not Integral.
> 
> It *does* have an Enum instance, so fromEnum shoiuld work.

Except that's not 2038-safe (fromEnum :: Enum a => a -> Int).

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/f958597d/attachment.sig>

From allbery.b at gmail.com  Wed Sep 16 14:06:44 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 16 Sep 2015 10:06:44 -0400
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <55F974AE.8000206@ro-che.info>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
 <CADS_YUzT=yOgVd5JvLBJLnH0ECnU6o4Db+Dt7mfnkaU2G6_ecw@mail.gmail.com>
 <CAKFCL4Ugyc1PpV4U42Oky9Pd8Zmv4-ELDtPePkbwDTQPaExNeQ@mail.gmail.com>
 <55F974AE.8000206@ro-che.info>
Message-ID: <CAKFCL4Umirc5vPaVpo-V_NKxHO7Cjmq3vYgmiPEeG2issqfrvw@mail.gmail.com>

On Wed, Sep 16, 2015 at 9:54 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> Except that's not 2038-safe (fromEnum :: Enum a => a -> Int).


Neither is EpochTime, to the extent that it is defined by Posix in a way
that is not Y2038 safe.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/abca5e3f/attachment.html>

From olf at aatal-apotheke.de  Wed Sep 16 14:38:37 2015
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Wed, 16 Sep 2015 16:38:37 +0200
Subject: [Haskell-cafe] Powerset of a set
Message-ID: <A5010D85-C5C7-48DC-BD19-EB3EAEF3DAE8@aatal-apotheke.de>

Jerzy is right, of course. I should have issued the warning to Jorge: If you just want to understand how to compute the powerset, don't look into filterM. But in a way, filterM works like Jerzy's Prolog example: 

filterM (const [False,True]) [] = [[]]
-- filterM is defined via foldr with base case (return []).

filterM (const [False,True]) (x:xs) = do

  includeFirstElement <- [False,True]
  -- in reality, includeFirstElem <- const [False,True] x

  subsetOfxs <- filterM (const [False,True] xs)
  -- recursive call.

  return (if includeFirstElement then x:subsetOfxs else subsetOfxs)

In order to produce a sublist of a list, 
we need to decide for each element if we want to include it in the sublist. That is, a sublist of xs :: [a] can be obtained by running 

  filter (p :: a -> Bool) xs

for some decision procedure p. The type of filterM allows the decision procedure to give more than one answer. In our case, the p, when asked "Should we include this particular element in the sublist?" always answers "Yes and No!". 

Is there a monad transformer generalisation of filterM, where the monad [] is replaced by other monad(-transformer)s? Recall that many monad transformers rely on distributive laws. 

class Distributive t where
  distrib :: (Monad m) => t (m a) -> m (t a)
instance Distributive [] where
  distrib = sequence

The term

  \p -> liftM (\x -> liftM (\b -> if b then return x else mzero) (p x))

can be given the type 

  (Monad m, MonadPlus t) => (a -> m Bool) -> t a -> t (m (t a))

Therefore the term 

  \p -> (liftM join).distrib.(liftM (\x -> liftM (\b -> if b then return x else mzero) (p x)))

can be given the type 

  (MonadPlus t,Distributive t, Monad m) => (a -> m Bool) -> t a -> m (t a)

Indeed for t = [] it is equivalent to filterM. To explain what's going on, notice that 

  sequence :: Monad m => [m a] -> m [a] 

computes, when m = [], all possible ways of picking one element from each list in a list of lists. One could say that sequence produces choice functions. I used sequence above: To compute the powerset of a set, replace each element x by the set {{},{x}}, then compute all choices, and then take the union of each such choice. 

-- Olaf

From kane at kane.cx  Wed Sep 16 14:53:34 2015
From: kane at kane.cx (David Kraeutmann)
Date: Wed, 16 Sep 2015 16:53:34 +0200
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <55F84BEE.2040709@kane.cx>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx>
Message-ID: <55F9826E.7000307@kane.cx>

I was looking at the wrong EpochTime, whoops.

On 9/15/2015 6:48 PM, David Kraeutmann wrote:
> EpochTime is an instance of Integral. You can just use toInteger ::
> Integral a => a -> Integer.
> On 9/15/2015 6:42 PM, Bram Neijt wrote:
>> Dear Haskell cafe,
>>
>> I want to convert form
>>
>> mtime :: System.Posix.Types.EpochTime
>>
>> to something aeson can eat without having to define an instance. I
>> choose Integer.
>>
>> My current solution[1] is just using (read . show). I know, ugly, but
>> the only thing I could get going.
>>
>> What is the proper way to convert System.Posix.Types.EpochTime to
>> Integer or something else aeson will automatically convert without
>> making a ToJSON instance?
>>
>> As a beginner I wonder: is there a general way to go about finding
>> conversion paths between types?
>>
>>
>> Greetings,
>>
>> Bram Neijt
>>
>> [1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/3be67653/attachment.bin>

From bneijt at gmail.com  Wed Sep 16 15:30:07 2015
From: bneijt at gmail.com (Bram Neijt)
Date: Wed, 16 Sep 2015 17:30:07 +0200
Subject: [Haskell-cafe] Converting EpochTime to Integer
In-Reply-To: <55F9826E.7000307@kane.cx>
References: <CADS_YUwKdJRuCkerjWsSjKxOwfDXhaJmS87GS_15yBCoi6s1hw@mail.gmail.com>
 <55F84BEE.2040709@kane.cx> <55F9826E.7000307@kane.cx>
Message-ID: <CADS_YUwUgFW8DS1jB=03CrE=fXPBkE6b5z4DJncO53MXHDKA+Q@mail.gmail.com>

Thank you all for your responses!

I've decided to use fromEnum (and I'm going to read up on how that works.)

Greetings,

Bram

On Wed, Sep 16, 2015 at 4:53 PM, David Kraeutmann <kane at kane.cx> wrote:
> I was looking at the wrong EpochTime, whoops.
>
> On 9/15/2015 6:48 PM, David Kraeutmann wrote:
>> EpochTime is an instance of Integral. You can just use toInteger ::
>> Integral a => a -> Integer.
>> On 9/15/2015 6:42 PM, Bram Neijt wrote:
>>> Dear Haskell cafe,
>>>
>>> I want to convert form
>>>
>>> mtime :: System.Posix.Types.EpochTime
>>>
>>> to something aeson can eat without having to define an instance. I
>>> choose Integer.
>>>
>>> My current solution[1] is just using (read . show). I know, ugly, but
>>> the only thing I could get going.
>>>
>>> What is the proper way to convert System.Posix.Types.EpochTime to
>>> Integer or something else aeson will automatically convert without
>>> making a ToJSON instance?
>>>
>>> As a beginner I wonder: is there a general way to go about finding
>>> conversion paths between types?
>>>
>>>
>>> Greetings,
>>>
>>> Bram Neijt
>>>
>>> [1] https://github.com/bneijt/httpmtimeline/blob/master/src/Main.hs#L21
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From kei at lanl.gov  Wed Sep 16 15:57:37 2015
From: kei at lanl.gov (Kei Davis)
Date: Wed, 16 Sep 2015 09:57:37 -0600
Subject: [Haskell-cafe] Simple question about blackholing
Message-ID: <55F99171.20902@lanl.gov>

Hello,

By all accounts I've found a thunk is blackholed by replacing its header 
with a (the) blackhole code pointer (or blackhole info pointer in the 
unregisterized case).  My simple-minded question is how garbage 
collection can take place given that the layout of the payload is lost.  
Surely not a custom blackhole for each (statically defined) thunk?  A 
list of blackholes maintained somewhere that the GC knows about?

Thanks for any insight!

Kei

-- 
Kei Davis
Applied Computer Science Group CCS-7, Mail Stop B287
Los Alamos National Laboratory
Los Alamos, NM 87545, U.S.A.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/750ca5c9/attachment.html>

From jmaessen at alum.mit.edu  Wed Sep 16 16:48:52 2015
From: jmaessen at alum.mit.edu (Jan-Willem Maessen)
Date: Wed, 16 Sep 2015 12:48:52 -0400
Subject: [Haskell-cafe] Simple question about blackholing
In-Reply-To: <55F99171.20902@lanl.gov>
References: <55F99171.20902@lanl.gov>
Message-ID: <CANs0n6wm30xS2MzXhf3T=iNz8K0DkZ4kYJisgJiapM4fBfGV+Q@mail.gmail.com>

I *believe* the answer is "Black holing happens as / after the thunk
contents are copied to the stack, so the contents of the thunk are now dead
and the data is live on a stack somewhere."

-Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/cbb1eae3/attachment.html>

From kei at lanl.gov  Wed Sep 16 17:37:19 2015
From: kei at lanl.gov (Kei Davis)
Date: Wed, 16 Sep 2015 11:37:19 -0600
Subject: [Haskell-cafe] Simple question about blackholing
In-Reply-To: <CANs0n6wm30xS2MzXhf3T=iNz8K0DkZ4kYJisgJiapM4fBfGV+Q@mail.gmail.com>
References: <55F99171.20902@lanl.gov>
 <CANs0n6wm30xS2MzXhf3T=iNz8K0DkZ4kYJisgJiapM4fBfGV+Q@mail.gmail.com>
Message-ID: <55F9A8CF.8000908@lanl.gov>

Jan,

I suppose things could have changed since 2005, but taking "Haskell on a 
Shared-Memory Multiprocessor" (Harris, Marlow, Peyton Jones 2005) as the 
reference point, the figure in section 3.3 makes clear that a thunk's 
payload (free variables) remains valid until update with an indirection.

The paper is also clear that there is only one header word, i.e., that a 
copy of the original header word isn't stashed in the header and that 
this header word is replaced with a blackhole (code pointer or info 
pointer).  They do not state outright that such a copy isn't stashed in 
the payload together with the free variables, but if that were the case 
it would seem an odd omission given the level of detail otherwise.

Kei

On 09/16/2015 10:48 AM, Jan-Willem Maessen wrote:
> I *believe* the answer is "Black holing happens as / after the thunk
> contents are copied to the stack, so the contents of the thunk are now
> dead and the data is live on a stack somewhere."
>
> -Jan

-- 
Kei Davis
Applied Computer Science Group CCS-7, Mail Stop B287
Los Alamos National Laboratory
Los Alamos, NM 87545, U.S.A.

From jmaessen at alum.mit.edu  Wed Sep 16 18:35:24 2015
From: jmaessen at alum.mit.edu (Jan-Willem Maessen)
Date: Wed, 16 Sep 2015 14:35:24 -0400
Subject: [Haskell-cafe] Simple question about blackholing
In-Reply-To: <55F9A8CF.8000908@lanl.gov>
References: <55F99171.20902@lanl.gov>
 <CANs0n6wm30xS2MzXhf3T=iNz8K0DkZ4kYJisgJiapM4fBfGV+Q@mail.gmail.com>
 <55F9A8CF.8000908@lanl.gov>
Message-ID: <CANs0n6y2hTBtV6NR=MPzKyVjZV74RG+XXpi6AHGAn97rqxFS7Q@mail.gmail.com>

Whoops, quite right, and ThreadPaused.c (
https://ghc.haskell.org/trac/ghc/browser/ghc/rts/ThreadPaused.c) makes
clear that there's only one Blackhole tag.

On Wed, Sep 16, 2015 at 1:37 PM, Kei Davis <kei at lanl.gov> wrote:

> Jan,
>
> I suppose things could have changed since 2005, but taking "Haskell on a
> Shared-Memory Multiprocessor" (Harris, Marlow, Peyton Jones 2005) as the
> reference point, the figure in section 3.3 makes clear that a thunk's
> payload (free variables) remains valid until update with an indirection.
>
> The paper is also clear that there is only one header word, i.e., that a
> copy of the original header word isn't stashed in the header and that this
> header word is replaced with a blackhole (code pointer or info pointer).
> They do not state outright that such a copy isn't stashed in the payload
> together with the free variables, but if that were the case it would seem
> an odd omission given the level of detail otherwise.
>
> Kei
>
>
> On 09/16/2015 10:48 AM, Jan-Willem Maessen wrote:
>
>> I *believe* the answer is "Black holing happens as / after the thunk
>> contents are copied to the stack, so the contents of the thunk are now
>> dead and the data is live on a stack somewhere."
>>
>> -Jan
>>
>
> --
> Kei Davis
> Applied Computer Science Group CCS-7, Mail Stop B287
> Los Alamos National Laboratory
> Los Alamos, NM 87545, U.S.A.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/f0377bc7/attachment.html>

From michael at schmong.org  Wed Sep 16 23:39:59 2015
From: michael at schmong.org (Michael Litchard)
Date: Wed, 16 Sep 2015 16:39:59 -0700
Subject: [Haskell-cafe] Looking for better than Dragon Book
Message-ID: <CAEzeKYp53sdO8BEqKgS3XrZhRPQkhNyKtd7-HeWGghHDGz2WHQ@mail.gmail.com>

I've got the Tiger Book, ML version, which I will use to help me implement
Tiger in Haskell.
Below is a class curriculum I've found. But besides the Tiger Book, it uses
the Dragon Book. I know there are more modern books out there. Looking for
suggestions as what might be a good fit.


http://cs.nyu.edu/courses/fall13/CSCI-GA.2130-001/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150916/cb85fe2d/attachment.html>

From dominic at steinitz.org  Thu Sep 17 08:13:19 2015
From: dominic at steinitz.org (Dominic Steinitz)
Date: Thu, 17 Sep 2015 09:13:19 +0100
Subject: [Haskell-cafe] GSoC Retrospective
Message-ID: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>

In past years, Gwern did an outstanding job of summarising the GSoC proposals and how well they had done: http://www.gwern.net/Haskell%20Summer%20of%20Code <http://www.gwern.net/Haskell%20Summer%20of%20Code>

Here are the proposals for this year. Perhaps students or their mentors could comment on how successful their projects have been? I realise this is a very poor substitute for Gwen?s analyses but it would better than nothing.

A Strict language pragma for GHC - Adam Sandberg Eriksson <https://github.com/adamse>
STM Data Structures Implementation <https://gist.github.com/Alllex/439480b7e80303f19ddc> - Alex Semin
Implementation of Layered Gramamar of Graphics <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu <https://github.com/AjayRamanathan/Plot>
Implementing Version Comparison for Cabal Packages - Craig Roche <https://github.com/cdxr>
Improving Hackage Discoverability <http://dzackgarza.com/mockup/main.html> - D. Zack Garza <https://github.com/dzackgarza>
Darcsden improvements <http://darcs.net/GSoC/2015-Darcsden> - Daniil Frumin <https://github.com/co-dan>
Pursuit enhancements <https://gist.github.com/hdgarrood/0a389937149453c69e03> - Harry Garrood <https://github.com/hdgarrood>
Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
A standalone functional parser for CommonMark <https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35> - Julien Cretel <https://github.com/Jubobs>
Refactor program with HLint suggestions <http://mpickering.github.io/gsoc2015.html> - Matthew Pickering <https://github.com/mpickering>
Replication back-end for acid-state - Max Voit
Native Haskell Type Encoding for LiquidHaskell <https://gist.github.com/spinda/b261167303515cc8a1d9> - Michael Smith <https://github.com/spinda>
Exhaustiveness Checker for PureScript - Nicolas Del Piano <https://github.com/nicodelpiano>
Fast splittable pseudorandom number generator for System.Random <https://gist.github.com/nkartashov/e46fd146b1df2d79aaf3> - Nikita Kartashov <https://github.com/nkartashov>
Interactive widgets in IHaskell <https://github.com/sumitsahrawat/gsoc/blob/master/2015/ihaskell.pdf> - Sumit Sahrawat <https://github.com/sumitsahrawat>
Improvements to yesod-devel - urbanslug <https://github.com/urbanslug>
Implement nix-like package management features in cabal <https://gist.github.com/fugyk/37510958b52589737274> - Vishal Agrawal <https://github.com/fugyk>
Haddock improvements - ?ukasz Hanuszczak <https://github.com/mrhania>

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/ddd7c860/attachment.html>

From dominic at steinitz.org  Thu Sep 17 08:18:03 2015
From: dominic at steinitz.org (Dominic Steinitz)
Date: Thu, 17 Sep 2015 09:18:03 +0100
Subject: [Haskell-cafe] GSoC Retrospective
In-Reply-To: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
Message-ID: <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>

For example, if I look at

>> Implementation of Layered Gramamar of Graphics <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu <https://github.com/AjayRamanathan/Plot>
I see the last commit was made on 30 June and the README says

> Working on a implementation of layered grammar of graphics. Work in progress, Nothing to see here, Move on.

I don?t wish to be judgemental but this rather looks like the goal was never achieved?

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com

> On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org> wrote:
> 
> In past years, Gwern did an outstanding job of summarising the GSoC proposals and how well they had done: http://www.gwern.net/Haskell%20Summer%20of%20Code <http://www.gwern.net/Haskell%20Summer%20of%20Code>
> 
> Here are the proposals for this year. Perhaps students or their mentors could comment on how successful their projects have been? I realise this is a very poor substitute for Gwen?s analyses but it would better than nothing.
> 
> A Strict language pragma for GHC - Adam Sandberg Eriksson <https://github.com/adamse>
> STM Data Structures Implementation <https://gist.github.com/Alllex/439480b7e80303f19ddc> - Alex Semin
> Implementation of Layered Gramamar of Graphics <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu <https://github.com/AjayRamanathan/Plot>
> Implementing Version Comparison for Cabal Packages - Craig Roche <https://github.com/cdxr>
> Improving Hackage Discoverability <http://dzackgarza.com/mockup/main.html> - D. Zack Garza <https://github.com/dzackgarza>
> Darcsden improvements <http://darcs.net/GSoC/2015-Darcsden> - Daniil Frumin <https://github.com/co-dan>
> Pursuit enhancements <https://gist.github.com/hdgarrood/0a389937149453c69e03> - Harry Garrood <https://github.com/hdgarrood>
> Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
> A standalone functional parser for CommonMark <https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35> - Julien Cretel <https://github.com/Jubobs>
> Refactor program with HLint suggestions <http://mpickering.github.io/gsoc2015.html> - Matthew Pickering <https://github.com/mpickering>
> Replication back-end for acid-state - Max Voit
> Native Haskell Type Encoding for LiquidHaskell <https://gist.github.com/spinda/b261167303515cc8a1d9> - Michael Smith <https://github.com/spinda>
> Exhaustiveness Checker for PureScript - Nicolas Del Piano <https://github.com/nicodelpiano>
> Fast splittable pseudorandom number generator for System.Random <https://gist.github.com/nkartashov/e46fd146b1df2d79aaf3> - Nikita Kartashov <https://github.com/nkartashov>
> Interactive widgets in IHaskell <https://github.com/sumitsahrawat/gsoc/blob/master/2015/ihaskell.pdf> - Sumit Sahrawat <https://github.com/sumitsahrawat>
> Improvements to yesod-devel - urbanslug <https://github.com/urbanslug>
> Implement nix-like package management features in cabal <https://gist.github.com/fugyk/37510958b52589737274> - Vishal Agrawal <https://github.com/fugyk>
> Haddock improvements - ?ukasz Hanuszczak <https://github.com/mrhania>
> 
> Dominic Steinitz
> dominic at steinitz.org <mailto:dominic at steinitz.org>
> http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/143a9954/attachment-0001.html>

From matthewtpickering at gmail.com  Thu Sep 17 09:05:51 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 17 Sep 2015 10:05:51 +0100
Subject: [Haskell-cafe] GSoC Retrospective
In-Reply-To: <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
 <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
Message-ID: <CALuQ0m-THCqs8KpORtfMTfiZ1p08Kw7hfC3-oFUnYYf1Yge0KQ@mail.gmail.com>

My project was refactoring programs with hlint suggestions. I'm
counting it as a success but I am waiting for a new release of HSE and
hlint before making an announcement. We can apply almost all
suggestions from hlint.

Here is a demo of it working -
https://camo.githubusercontent.com/a928338441f119fa911151c0db0ceaa72c51e0c4/687474703a2f2f692e696d6775722e636f6d2f3759586f5666742e676966

Matt

On Thu, Sep 17, 2015 at 9:18 AM, Dominic Steinitz <dominic at steinitz.org> wrote:
> For example, if I look at
>
> Implementation of Layered Gramamar of Graphics - chinu
>
>
> I see the last commit was made on 30 June and the README says
>
> Working on a implementation of layered grammar of graphics. Work in
> progress, Nothing to see here, Move on.
>
>
> I don?t wish to be judgemental but this rather looks like the goal was never
> achieved?
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org> wrote:
>
> In past years, Gwern did an outstanding job of summarising the GSoC
> proposals and how well they had done:
> http://www.gwern.net/Haskell%20Summer%20of%20Code
>
> Here are the proposals for this year. Perhaps students or their mentors
> could comment on how successful their projects have been? I realise this is
> a very poor substitute for Gwen?s analyses but it would better than nothing.
>
> A Strict language pragma for GHC - Adam Sandberg Eriksson
> STM Data Structures Implementation - Alex Semin
> Implementation of Layered Gramamar of Graphics - chinu
> Implementing Version Comparison for Cabal Packages - Craig Roche
> Improving Hackage Discoverability - D. Zack Garza
> Darcsden improvements - Daniil Frumin
> Pursuit enhancements - Harry Garrood
> Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
> A standalone functional parser for CommonMark - Julien Cretel
> Refactor program with HLint suggestions - Matthew Pickering
> Replication back-end for acid-state - Max Voit
> Native Haskell Type Encoding for LiquidHaskell - Michael Smith
> Exhaustiveness Checker for PureScript - Nicolas Del Piano
> Fast splittable pseudorandom number generator for System.Random - Nikita
> Kartashov
> Interactive widgets in IHaskell - Sumit Sahrawat
> Improvements to yesod-devel - urbanslug
> Implement nix-like package management features in cabal - Vishal Agrawal
> Haddock improvements - ?ukasz Hanuszczak
>
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From dominic at steinitz.org  Thu Sep 17 09:49:22 2015
From: dominic at steinitz.org (Dominic Steinitz)
Date: Thu, 17 Sep 2015 10:49:22 +0100
Subject: [Haskell-cafe] GSoC Retrospective
In-Reply-To: <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
 <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
Message-ID: <CC46E038-EE64-4173-B50A-5C90B3C90E95@steinitz.org>

I have created a wiki page here: https://wiki.haskell.org/Google_summer_of_code#Accepted_GSOC2015_projects <https://wiki.haskell.org/Google_summer_of_code#Accepted_GSOC2015_projects>

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com

> On 17 Sep 2015, at 09:18, Dominic Steinitz <dominic at steinitz.org> wrote:
> 
> For example, if I look at
> 
>>> Implementation of Layered Gramamar of Graphics <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu <https://github.com/AjayRamanathan/Plot>
> I see the last commit was made on 30 June and the README says
> 
>> Working on a implementation of layered grammar of graphics. Work in progress, Nothing to see here, Move on.
> 
> I don?t wish to be judgemental but this rather looks like the goal was never achieved?
> 
> Dominic Steinitz
> dominic at steinitz.org <mailto:dominic at steinitz.org>
> http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/>
>> On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org <mailto:dominic at steinitz.org>> wrote:
>> 
>> In past years, Gwern did an outstanding job of summarising the GSoC proposals and how well they had done: http://www.gwern.net/Haskell%20Summer%20of%20Code <http://www.gwern.net/Haskell%20Summer%20of%20Code>
>> 
>> Here are the proposals for this year. Perhaps students or their mentors could comment on how successful their projects have been? I realise this is a very poor substitute for Gwen?s analyses but it would better than nothing.
>> 
>> A Strict language pragma for GHC - Adam Sandberg Eriksson <https://github.com/adamse>
>> STM Data Structures Implementation <https://gist.github.com/Alllex/439480b7e80303f19ddc> - Alex Semin
>> Implementation of Layered Gramamar of Graphics <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu <https://github.com/AjayRamanathan/Plot>
>> Implementing Version Comparison for Cabal Packages - Craig Roche <https://github.com/cdxr>
>> Improving Hackage Discoverability <http://dzackgarza.com/mockup/main.html> - D. Zack Garza <https://github.com/dzackgarza>
>> Darcsden improvements <http://darcs.net/GSoC/2015-Darcsden> - Daniil Frumin <https://github.com/co-dan>
>> Pursuit enhancements <https://gist.github.com/hdgarrood/0a389937149453c69e03> - Harry Garrood <https://github.com/hdgarrood>
>> Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
>> A standalone functional parser for CommonMark <https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35> - Julien Cretel <https://github.com/Jubobs>
>> Refactor program with HLint suggestions <http://mpickering.github.io/gsoc2015.html> - Matthew Pickering <https://github.com/mpickering>
>> Replication back-end for acid-state - Max Voit
>> Native Haskell Type Encoding for LiquidHaskell <https://gist.github.com/spinda/b261167303515cc8a1d9> - Michael Smith <https://github.com/spinda>
>> Exhaustiveness Checker for PureScript - Nicolas Del Piano <https://github.com/nicodelpiano>
>> Fast splittable pseudorandom number generator for System.Random <https://gist.github.com/nkartashov/e46fd146b1df2d79aaf3> - Nikita Kartashov <https://github.com/nkartashov>
>> Interactive widgets in IHaskell <https://github.com/sumitsahrawat/gsoc/blob/master/2015/ihaskell.pdf> - Sumit Sahrawat <https://github.com/sumitsahrawat>
>> Improvements to yesod-devel - urbanslug <https://github.com/urbanslug>
>> Implement nix-like package management features in cabal <https://gist.github.com/fugyk/37510958b52589737274> - Vishal Agrawal <https://github.com/fugyk>
>> Haddock improvements - ?ukasz Hanuszczak <https://github.com/mrhania>
>> 
>> Dominic Steinitz
>> dominic at steinitz.org <mailto:dominic at steinitz.org>
>> http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/57bc044b/attachment.html>

From agocorona at gmail.com  Thu Sep 17 09:50:11 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 17 Sep 2015 11:50:11 +0200
Subject: [Haskell-cafe] test socket buffer full
Message-ID: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>

Hi haskellers

I?m implementing a form of intelligent streaming among nodes so that a
process could know if there are bottlenecks on sending/receiving data so
the process can increase or decrease the number of worker threads, for
example.

For this purpose, I planned to use hPutBufNonBlocking and
hGetBufNonBlocking to detect when the buffer is full,  using block
buffering.

I created hPutStrLn' that tries to write the entire string in the buffer.
if it does not fit, the process would be notified in a state variable, then
it would do a flush of the buffer and the rest of the string would be sent
with hPutBuf. Doing some tinkering here and there It came up to be this:

hPutStrLn' h str= do let bs@(PS ps s l) = BS.pack $ str ++ "\n" n <-
withForeignPtr ps $ \p-> hPutBufNonBlocking h (p `plusPtr` s) l when( n <
l) $ do error "BUFFER
FULLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL" hFlush h
withForeignPtr ps $ \p -> hPutBuf h ( p `plusPtr` (n * sizeOf 'x' ) ) (l -
n) return ()

The error condition is the one that I expected to detect in the tests. In
the real code, this line just would set a state variable, that would be
read by the process somewhere else.

The problem is that this routine behaves identically to hPutStrLn.  The
error condition never happens and hPutBufNonBlocking send the complete
string every time.

I created a program

https://gist.github.com/agocorona/6568bd61d71ab921ad0c

The example print  the output of the receiver "hello"  continuously

Note that in the complete running code below, the receiver has a
threadDelay of a second, so the send and receive buffers should be full.

That happens in Windows and Linux, in a single process (like in the
example) or within two processes in the same machine.

How the processes can detect the congestion?


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/26bf7dbe/attachment.html>

From sumit.sahrawat.apm13 at iitbhu.ac.in  Thu Sep 17 10:05:34 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Thu, 17 Sep 2015 15:35:34 +0530
Subject: [Haskell-cafe] GSoC Retrospective
In-Reply-To: <CC46E038-EE64-4173-B50A-5C90B3C90E95@steinitz.org>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
 <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
 <CC46E038-EE64-4173-B50A-5C90B3C90E95@steinitz.org>
Message-ID: <CAJbEW8O1iNTzUTryxn+gHuBbjJThgTbfPd5-BeuOom+M8aMdWw@mail.gmail.com>

My project "Interactive widgets in IHaskell" was completed successfully.
We'll be having a public announcement with an online demo on try.jupyter.org
soon.

On 17 September 2015 at 15:19, Dominic Steinitz <dominic at steinitz.org>
wrote:

> I have created a wiki page here:
> https://wiki.haskell.org/Google_summer_of_code#Accepted_GSOC2015_projects
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> On 17 Sep 2015, at 09:18, Dominic Steinitz <dominic at steinitz.org> wrote:
>
> For example, if I look at
>
>
>    - Implementation of Layered Gramamar of Graphics
>    <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu
>    <https://github.com/AjayRamanathan/Plot>
>
>
> I see the last commit was made on 30 June and the README says
>
> Working on a implementation of layered grammar of graphics. Work in
> progress, Nothing to see here, Move on.
>
>
> I don?t wish to be judgemental but this rather looks like the goal was
> never achieved?
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org> wrote:
>
> In past years, Gwern did an outstanding job of summarising the GSoC
> proposals and how well they had done:
> http://www.gwern.net/Haskell%20Summer%20of%20Code
>
> Here are the proposals for this year. Perhaps students or their mentors
> could comment on how successful their projects have been? I realise this is
> a very poor substitute for Gwen?s analyses but it would better than nothing.
>
>
>    - A Strict language pragma for GHC - Adam Sandberg Eriksson
>    <https://github.com/adamse>
>    - STM Data Structures Implementation
>    <https://gist.github.com/Alllex/439480b7e80303f19ddc> - Alex Semin
>    - Implementation of Layered Gramamar of Graphics
>    <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu
>    <https://github.com/AjayRamanathan/Plot>
>    - Implementing Version Comparison for Cabal Packages - Craig Roche
>    <https://github.com/cdxr>
>    - Improving Hackage Discoverability
>    <http://dzackgarza.com/mockup/main.html> - D. Zack Garza
>    <https://github.com/dzackgarza>
>    - Darcsden improvements <http://darcs.net/GSoC/2015-Darcsden> - Daniil
>    Frumin <https://github.com/co-dan>
>    - Pursuit enhancements
>    <https://gist.github.com/hdgarrood/0a389937149453c69e03> - Harry
>    Garrood <https://github.com/hdgarrood>
>    - Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
>    - A standalone functional parser for CommonMark
>    <https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35> - Julien Cretel
>    <https://github.com/Jubobs>
>    - Refactor program with HLint suggestions
>    <http://mpickering.github.io/gsoc2015.html> - Matthew Pickering
>    <https://github.com/mpickering>
>    - Replication back-end for acid-state - Max Voit
>    - Native Haskell Type Encoding for LiquidHaskell
>    <https://gist.github.com/spinda/b261167303515cc8a1d9> - Michael Smith
>    <https://github.com/spinda>
>    - Exhaustiveness Checker for PureScript - Nicolas Del Piano
>    <https://github.com/nicodelpiano>
>    - Fast splittable pseudorandom number generator for System.Random
>    <https://gist.github.com/nkartashov/e46fd146b1df2d79aaf3> - Nikita
>    Kartashov <https://github.com/nkartashov>
>    - Interactive widgets in IHaskell
>    <https://github.com/sumitsahrawat/gsoc/blob/master/2015/ihaskell.pdf>
>     - Sumit Sahrawat <https://github.com/sumitsahrawat>
>    - Improvements to yesod-devel - urbanslug
>    <https://github.com/urbanslug>
>    - Implement nix-like package management features in cabal
>    <https://gist.github.com/fugyk/37510958b52589737274> - Vishal Agrawal
>    <https://github.com/fugyk>
>    - Haddock improvements - ?ukasz Hanuszczak <https://github.com/mrhania>
>
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/b6e0ea70/attachment.html>

From gk at ninebynine.org  Thu Sep 17 10:38:34 2015
From: gk at ninebynine.org (Graham Klyne)
Date: Thu, 17 Sep 2015 11:38:34 +0100
Subject: [Haskell-cafe] Interactive widgets;
	formlets (was: GSoC Retrospective)
In-Reply-To: <CAJbEW8O1iNTzUTryxn+gHuBbjJThgTbfPd5-BeuOom+M8aMdWw@mail.gmail.com>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
 <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
 <CC46E038-EE64-4173-B50A-5C90B3C90E95@steinitz.org>
 <CAJbEW8O1iNTzUTryxn+gHuBbjJThgTbfPd5-BeuOom+M8aMdWw@mail.gmail.com>
Message-ID: <55FA982A.70304@ninebynine.org>

Hi,

I spotted this project and my interest was piqued.  I am particularly wondering 
if there's scope in some future development to exploit ideas of formlets/form 
lenses:

   - http://homepages.inf.ed.ac.uk/slindley/papers/formlenses-bx13.pdf
   - http://homepages.inf.ed.ac.uk/slindley/papers/formlets-essence.pdf
   - http://groups.inf.ed.ac.uk/links/papers/formlets-tr2008.pdf

(I'm currently working on a project in Python that could benefit from these 
ideas, but I'm not yet ready to refactor everything because some requirements 
are still emerging.)

#g
--


On 17/09/2015 11:05, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote:
> My project "Interactive widgets in IHaskell" was completed successfully.
> We'll be having a public announcement with an online demo on try.jupyter.org
> soon.
>
> On 17 September 2015 at 15:19, Dominic Steinitz <dominic at steinitz.org>
> wrote:
>
>> I have created a wiki page here:
>> https://wiki.haskell.org/Google_summer_of_code#Accepted_GSOC2015_projects
>>
>> Dominic Steinitz
>> dominic at steinitz.org
>> http://idontgetoutmuch.wordpress.com
>>
>> On 17 Sep 2015, at 09:18, Dominic Steinitz <dominic at steinitz.org> wrote:
>>
>> For example, if I look at
>>
>>
>>     - Implementation of Layered Gramamar of Graphics
>>     <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu
>>     <https://github.com/AjayRamanathan/Plot>
>>
>>
>> I see the last commit was made on 30 June and the README says
>>
>> Working on a implementation of layered grammar of graphics. Work in
>> progress, Nothing to see here, Move on.
>>
>>
>> I don?t wish to be judgemental but this rather looks like the goal was
>> never achieved?
>>
>> Dominic Steinitz
>> dominic at steinitz.org
>> http://idontgetoutmuch.wordpress.com
>>
>> On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org> wrote:
>>
>> In past years, Gwern did an outstanding job of summarising the GSoC
>> proposals and how well they had done:
>> http://www.gwern.net/Haskell%20Summer%20of%20Code
>>
>> Here are the proposals for this year. Perhaps students or their mentors
>> could comment on how successful their projects have been? I realise this is
>> a very poor substitute for Gwen?s analyses but it would better than nothing.
>>
>>
>>     - A Strict language pragma for GHC - Adam Sandberg Eriksson
>>     <https://github.com/adamse>
>>     - STM Data Structures Implementation
>>     <https://gist.github.com/Alllex/439480b7e80303f19ddc> - Alex Semin
>>     - Implementation of Layered Gramamar of Graphics
>>     <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu
>>     <https://github.com/AjayRamanathan/Plot>
>>     - Implementing Version Comparison for Cabal Packages - Craig Roche
>>     <https://github.com/cdxr>
>>     - Improving Hackage Discoverability
>>     <http://dzackgarza.com/mockup/main.html> - D. Zack Garza
>>     <https://github.com/dzackgarza>
>>     - Darcsden improvements <http://darcs.net/GSoC/2015-Darcsden> - Daniil
>>     Frumin <https://github.com/co-dan>
>>     - Pursuit enhancements
>>     <https://gist.github.com/hdgarrood/0a389937149453c69e03> - Harry
>>     Garrood <https://github.com/hdgarrood>
>>     - Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
>>     - A standalone functional parser for CommonMark
>>     <https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35> - Julien Cretel
>>     <https://github.com/Jubobs>
>>     - Refactor program with HLint suggestions
>>     <http://mpickering.github.io/gsoc2015.html> - Matthew Pickering
>>     <https://github.com/mpickering>
>>     - Replication back-end for acid-state - Max Voit
>>     - Native Haskell Type Encoding for LiquidHaskell
>>     <https://gist.github.com/spinda/b261167303515cc8a1d9> - Michael Smith
>>     <https://github.com/spinda>
>>     - Exhaustiveness Checker for PureScript - Nicolas Del Piano
>>     <https://github.com/nicodelpiano>
>>     - Fast splittable pseudorandom number generator for System.Random
>>     <https://gist.github.com/nkartashov/e46fd146b1df2d79aaf3> - Nikita
>>     Kartashov <https://github.com/nkartashov>
>>     - Interactive widgets in IHaskell
>>     <https://github.com/sumitsahrawat/gsoc/blob/master/2015/ihaskell.pdf>
>>      - Sumit Sahrawat <https://github.com/sumitsahrawat>
>>     - Improvements to yesod-devel - urbanslug
>>     <https://github.com/urbanslug>
>>     - Implement nix-like package management features in cabal
>>     <https://gist.github.com/fugyk/37510958b52589737274> - Vishal Agrawal
>>     <https://github.com/fugyk>
>>     - Haddock improvements - ?ukasz Hanuszczak <https://github.com/mrhania>
>>
>>
>> Dominic Steinitz
>> dominic at steinitz.org
>> http://idontgetoutmuch.wordpress.com
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From sumit.sahrawat.apm13 at iitbhu.ac.in  Thu Sep 17 11:23:28 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Thu, 17 Sep 2015 16:53:28 +0530
Subject: [Haskell-cafe] Interactive widgets;
	formlets (was: GSoC Retrospective)
In-Reply-To: <55FA982A.70304@ninebynine.org>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
 <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
 <CC46E038-EE64-4173-B50A-5C90B3C90E95@steinitz.org>
 <CAJbEW8O1iNTzUTryxn+gHuBbjJThgTbfPd5-BeuOom+M8aMdWw@mail.gmail.com>
 <55FA982A.70304@ninebynine.org>
Message-ID: <CAJbEW8P0jOB8dSV-3X2FP67Y5gKbvGzgLX7xf5jh+6p-55arTw@mail.gmail.com>

My project was to implement support for IPywidgets (
https://github.com/ipython/ipywidgets), in IHaskell (
https://github.com/gibiansky/IHaskell). You should look at IPywidgets if
you're interested in working with widgets in Python.

The IPywidgets have some javascript that runs in the Jupyter notebook
frontend, and some python code that integrates with IPython to provide
support for them. My project reused the javascript provided by IPywidgets,
and implemented support for them inside IHaskell.

The formlets idea can be easily applied here. For example, one can
implement the date picker example from the papers by creating a module that
exports:

    mkDateFormlet :: IO (Box, IO (Maybe Date))

Here, `Box` is a widget from `ihaskell-widgets` that can hold more widgets
inside it. In our case, it may hold any widgets that can be used to read a
date.

The `IO (Maybe Date)` can be used to read a date from the `Box` that we
provided. As the Box is a widget, it can be displayed inside the jupyter
notebook.

These two together constitute a formlet. Am I right in saying this?

This will make for a good example, I'll implement this as an example
notebook for the online demo. Thanks for the great idea.

On 17 September 2015 at 16:08, Graham Klyne <gk at ninebynine.org> wrote:

> Hi,
>
> I spotted this project and my interest was piqued.  I am particularly
> wondering if there's scope in some future development to exploit ideas of
> formlets/form lenses:
>
>   - http://homepages.inf.ed.ac.uk/slindley/papers/formlenses-bx13.pdf
>   - http://homepages.inf.ed.ac.uk/slindley/papers/formlets-essence.pdf
>   - http://groups.inf.ed.ac.uk/links/papers/formlets-tr2008.pdf
>
> (I'm currently working on a project in Python that could benefit from
> these ideas, but I'm not yet ready to refactor everything because some
> requirements are still emerging.)
>
> #g
> --
>
>
> On 17/09/2015 11:05, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote:
>
>> My project "Interactive widgets in IHaskell" was completed successfully.
>> We'll be having a public announcement with an online demo on
>> try.jupyter.org
>> soon.
>>
>> On 17 September 2015 at 15:19, Dominic Steinitz <dominic at steinitz.org>
>> wrote:
>>
>> I have created a wiki page here:
>>> https://wiki.haskell.org/Google_summer_of_code#Accepted_GSOC2015_projects
>>>
>>> Dominic Steinitz
>>> dominic at steinitz.org
>>> http://idontgetoutmuch.wordpress.com
>>>
>>> On 17 Sep 2015, at 09:18, Dominic Steinitz <dominic at steinitz.org> wrote:
>>>
>>> For example, if I look at
>>>
>>>
>>>     - Implementation of Layered Gramamar of Graphics
>>>     <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> -
>>> chinu
>>>     <https://github.com/AjayRamanathan/Plot>
>>>
>>>
>>> I see the last commit was made on 30 June and the README says
>>>
>>> Working on a implementation of layered grammar of graphics. Work in
>>> progress, Nothing to see here, Move on.
>>>
>>>
>>> I don?t wish to be judgemental but this rather looks like the goal was
>>> never achieved?
>>>
>>> Dominic Steinitz
>>> dominic at steinitz.org
>>> http://idontgetoutmuch.wordpress.com
>>>
>>> On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org> wrote:
>>>
>>> In past years, Gwern did an outstanding job of summarising the GSoC
>>> proposals and how well they had done:
>>> http://www.gwern.net/Haskell%20Summer%20of%20Code
>>>
>>> Here are the proposals for this year. Perhaps students or their mentors
>>> could comment on how successful their projects have been? I realise this
>>> is
>>> a very poor substitute for Gwen?s analyses but it would better than
>>> nothing.
>>>
>>>
>>>     - A Strict language pragma for GHC - Adam Sandberg Eriksson
>>>     <https://github.com/adamse>
>>>     - STM Data Structures Implementation
>>>     <https://gist.github.com/Alllex/439480b7e80303f19ddc> - Alex Semin
>>>     - Implementation of Layered Gramamar of Graphics
>>>     <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> -
>>> chinu
>>>     <https://github.com/AjayRamanathan/Plot>
>>>     - Implementing Version Comparison for Cabal Packages - Craig Roche
>>>     <https://github.com/cdxr>
>>>     - Improving Hackage Discoverability
>>>     <http://dzackgarza.com/mockup/main.html> - D. Zack Garza
>>>     <https://github.com/dzackgarza>
>>>     - Darcsden improvements <http://darcs.net/GSoC/2015-Darcsden> -
>>> Daniil
>>>     Frumin <https://github.com/co-dan>
>>>     - Pursuit enhancements
>>>     <https://gist.github.com/hdgarrood/0a389937149453c69e03> - Harry
>>>     Garrood <https://github.com/hdgarrood>
>>>     - Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
>>>     - A standalone functional parser for CommonMark
>>>     <https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35> - Julien
>>> Cretel
>>>     <https://github.com/Jubobs>
>>>     - Refactor program with HLint suggestions
>>>     <http://mpickering.github.io/gsoc2015.html> - Matthew Pickering
>>>     <https://github.com/mpickering>
>>>     - Replication back-end for acid-state - Max Voit
>>>     - Native Haskell Type Encoding for LiquidHaskell
>>>     <https://gist.github.com/spinda/b261167303515cc8a1d9> - Michael
>>> Smith
>>>     <https://github.com/spinda>
>>>     - Exhaustiveness Checker for PureScript - Nicolas Del Piano
>>>     <https://github.com/nicodelpiano>
>>>     - Fast splittable pseudorandom number generator for System.Random
>>>     <https://gist.github.com/nkartashov/e46fd146b1df2d79aaf3> - Nikita
>>>     Kartashov <https://github.com/nkartashov>
>>>     - Interactive widgets in IHaskell
>>>     <https://github.com/sumitsahrawat/gsoc/blob/master/2015/ihaskell.pdf
>>> >
>>>      - Sumit Sahrawat <https://github.com/sumitsahrawat>
>>>     - Improvements to yesod-devel - urbanslug
>>>     <https://github.com/urbanslug>
>>>     - Implement nix-like package management features in cabal
>>>     <https://gist.github.com/fugyk/37510958b52589737274> - Vishal
>>> Agrawal
>>>     <https://github.com/fugyk>
>>>     - Haddock improvements - ?ukasz Hanuszczak <
>>> https://github.com/mrhania>
>>>
>>>
>>> Dominic Steinitz
>>> dominic at steinitz.org
>>> http://idontgetoutmuch.wordpress.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>


-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/accaf62d/attachment.html>

From allbery.b at gmail.com  Thu Sep 17 12:09:14 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 17 Sep 2015 08:09:14 -0400
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
Message-ID: <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>

On Thu, Sep 17, 2015 at 5:50 AM, Alberto G. Corona <agocorona at gmail.com>
wrote:

> That happens in Windows and Linux, in a single process (like in the
> example) or within two processes in the same machine.


I'm a little surprised this program works at all on Windows, because the
winsock stuff gets torn down when `withSocketsDo $ listenOn port` is done?
And you do other socket ops outside of withSocketsDo.

Otherwise, it looks like you check for n < 1, not n < l; you would only
detect buffer-full if the entire write failed, not for partial writes.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/d9c9c2f5/attachment.html>

From agocorona at gmail.com  Thu Sep 17 12:46:01 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 17 Sep 2015 14:46:01 +0200
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
 <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
Message-ID: <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>

It apparently works under ghc 7.8.3 and windows 10. anyway I did not
noticed it.
I  usually  insert withSocketsDo too.

2015-09-17 14:09 GMT+02:00 Brandon Allbery <allbery.b at gmail.com>:

> On Thu, Sep 17, 2015 at 5:50 AM, Alberto G. Corona <agocorona at gmail.com>
> wrote:
>
>> That happens in Windows and Linux, in a single process (like in the
>> example) or within two processes in the same machine.
>
>
> I'm a little surprised this program works at all on Windows, because the
> winsock stuff gets torn down when `withSocketsDo $ listenOn port` is done?
> And you do other socket ops outside of withSocketsDo.
>
> Otherwise, it looks like you check for n < 1, not n < l; you would only
> detect buffer-full if the entire write failed, not for partial writes.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/8debba28/attachment.html>

From allbery.b at gmail.com  Thu Sep 17 12:52:31 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 17 Sep 2015 08:52:31 -0400
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
 <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
 <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>
Message-ID: <CAKFCL4UNrP_LHJqBU+CUaTfpRRkOGngh51G2GcL8vxA9+Bv=7g@mail.gmail.com>

On Thu, Sep 17, 2015 at 8:46 AM, Alberto G. Corona <agocorona at gmail.com>
wrote:

> It apparently works under ghc 7.8.3 and windows 10. anyway I did not
> noticed it.
> I  usually  insert withSocketsDo too.
>

It is possible that recent network package changed this, but in the past
*all* socket operations had to be under the aegis of *one* withSocketsDo,
otherwise any handles, buffers, etc. would become invalid when Winsock was
deinitialized.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/a08f0259/attachment.html>

From mantkiew at gsd.uwaterloo.ca  Thu Sep 17 13:22:03 2015
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Thu, 17 Sep 2015 09:22:03 -0400
Subject: [Haskell-cafe] GSoC Retrospective
In-Reply-To: <CALuQ0m-THCqs8KpORtfMTfiZ1p08Kw7hfC3-oFUnYYf1Yge0KQ@mail.gmail.com>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
 <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
 <CALuQ0m-THCqs8KpORtfMTfiZ1p08Kw7hfC3-oFUnYYf1Yge0KQ@mail.gmail.com>
Message-ID: <CAGW9QSxjUZ_GzE8DBHfBd395Gfv84DORJUXd9SnBPp+g4EWtZA@mail.gmail.com>

Matthew, that looks great!

How is the tool going to be distributed? Is it part of something (like
ghc-mod) or standalone?

Cheers,
Micha?

On Thu, Sep 17, 2015 at 5:05 AM, Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> My project was refactoring programs with hlint suggestions. I'm
> counting it as a success but I am waiting for a new release of HSE and
> hlint before making an announcement. We can apply almost all
> suggestions from hlint.
>
> Here is a demo of it working -
>
> https://camo.githubusercontent.com/a928338441f119fa911151c0db0ceaa72c51e0c4/687474703a2f2f692e696d6775722e636f6d2f3759586f5666742e676966
>
> Matt
>
> On Thu, Sep 17, 2015 at 9:18 AM, Dominic Steinitz <dominic at steinitz.org>
> wrote:
> > For example, if I look at
> >
> > Implementation of Layered Gramamar of Graphics - chinu
> >
> >
> > I see the last commit was made on 30 June and the README says
> >
> > Working on a implementation of layered grammar of graphics. Work in
> > progress, Nothing to see here, Move on.
> >
> >
> > I don?t wish to be judgemental but this rather looks like the goal was
> never
> > achieved?
> >
> > Dominic Steinitz
> > dominic at steinitz.org
> > http://idontgetoutmuch.wordpress.com
> >
> > On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org> wrote:
> >
> > In past years, Gwern did an outstanding job of summarising the GSoC
> > proposals and how well they had done:
> > http://www.gwern.net/Haskell%20Summer%20of%20Code
> >
> > Here are the proposals for this year. Perhaps students or their mentors
> > could comment on how successful their projects have been? I realise this
> is
> > a very poor substitute for Gwen?s analyses but it would better than
> nothing.
> >
> > A Strict language pragma for GHC - Adam Sandberg Eriksson
> > STM Data Structures Implementation - Alex Semin
> > Implementation of Layered Gramamar of Graphics - chinu
> > Implementing Version Comparison for Cabal Packages - Craig Roche
> > Improving Hackage Discoverability - D. Zack Garza
> > Darcsden improvements - Daniil Frumin
> > Pursuit enhancements - Harry Garrood
> > Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
> > A standalone functional parser for CommonMark - Julien Cretel
> > Refactor program with HLint suggestions - Matthew Pickering
> > Replication back-end for acid-state - Max Voit
> > Native Haskell Type Encoding for LiquidHaskell - Michael Smith
> > Exhaustiveness Checker for PureScript - Nicolas Del Piano
> > Fast splittable pseudorandom number generator for System.Random - Nikita
> > Kartashov
> > Interactive widgets in IHaskell - Sumit Sahrawat
> > Improvements to yesod-devel - urbanslug
> > Implement nix-like package management features in cabal - Vishal Agrawal
> > Haddock improvements - ?ukasz Hanuszczak
> >
> >
> > Dominic Steinitz
> > dominic at steinitz.org
> > http://idontgetoutmuch.wordpress.com
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/9e9536b4/attachment.html>

From james at mansionfamily.plus.com  Thu Sep 17 13:41:30 2015
From: james at mansionfamily.plus.com (james)
Date: Thu, 17 Sep 2015 14:41:30 +0100
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <CAKFCL4UNrP_LHJqBU+CUaTfpRRkOGngh51G2GcL8vxA9+Bv=7g@mail.gmail.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
 <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
 <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>
 <CAKFCL4UNrP_LHJqBU+CUaTfpRRkOGngh51G2GcL8vxA9+Bv=7g@mail.gmail.com>
Message-ID: <55FAC30A.9020005@mansionfamily.plus.com>

On 17/09/2015 13:52, Brandon Allbery wrote:
> ...
> It is possible that recent network package changed this, but in the 
> past *all* socket operations had to be under the aegis of *one* 
> withSocketsDo, otherwise any handles, buffers, etc. would become 
> invalid when Winsock was deinitialized.

See 
http://neilmitchell.blogspot.co.uk/2015/02/making-withsocketsdo-unnecessary.html


From johan.tibell at gmail.com  Thu Sep 17 13:53:59 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 17 Sep 2015 15:53:59 +0200
Subject: [Haskell-cafe] GSoC Retrospective
In-Reply-To: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
Message-ID: <CAK-tuPbBZo-tk0HmdisMpVmekS_XcNRtkwtLuwvaH2oXbFWezA@mail.gmail.com>

I'm very happy with Adam's work strict Haskell. StrictData is already in
HEAD and will be part of 8.0. Adam is working (as his studies permit) of
finish the rest. Perhaps if we're really lucky we'll have the Strict pragma
as well in 8.0.

On Thu, Sep 17, 2015 at 10:13 AM, Dominic Steinitz <dominic at steinitz.org>
wrote:

> In past years, Gwern did an outstanding job of summarising the GSoC
> proposals and how well they had done:
> http://www.gwern.net/Haskell%20Summer%20of%20Code
>
> Here are the proposals for this year. Perhaps students or their mentors
> could comment on how successful their projects have been? I realise this is
> a very poor substitute for Gwen?s analyses but it would better than nothing.
>
>
>    - A Strict language pragma for GHC - Adam Sandberg Eriksson
>    <https://github.com/adamse>
>    - STM Data Structures Implementation
>    <https://gist.github.com/Alllex/439480b7e80303f19ddc> - Alex Semin
>    - Implementation of Layered Gramamar of Graphics
>    <https://gist.github.com/AjayRamanathan/c84a4641836700a2547b> - chinu
>    <https://github.com/AjayRamanathan/Plot>
>    - Implementing Version Comparison for Cabal Packages - Craig Roche
>    <https://github.com/cdxr>
>    - Improving Hackage Discoverability
>    <http://dzackgarza.com/mockup/main.html> - D. Zack Garza
>    <https://github.com/dzackgarza>
>    - Darcsden improvements <http://darcs.net/GSoC/2015-Darcsden> - Daniil
>    Frumin <https://github.com/co-dan>
>    - Pursuit enhancements
>    <https://gist.github.com/hdgarrood/0a389937149453c69e03> - Harry
>    Garrood <https://github.com/hdgarrood>
>    - Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
>    - A standalone functional parser for CommonMark
>    <https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35> - Julien Cretel
>    <https://github.com/Jubobs>
>    - Refactor program with HLint suggestions
>    <http://mpickering.github.io/gsoc2015.html> - Matthew Pickering
>    <https://github.com/mpickering>
>    - Replication back-end for acid-state - Max Voit
>    - Native Haskell Type Encoding for LiquidHaskell
>    <https://gist.github.com/spinda/b261167303515cc8a1d9> - Michael Smith
>    <https://github.com/spinda>
>    - Exhaustiveness Checker for PureScript - Nicolas Del Piano
>    <https://github.com/nicodelpiano>
>    - Fast splittable pseudorandom number generator for System.Random
>    <https://gist.github.com/nkartashov/e46fd146b1df2d79aaf3> - Nikita
>    Kartashov <https://github.com/nkartashov>
>    - Interactive widgets in IHaskell
>    <https://github.com/sumitsahrawat/gsoc/blob/master/2015/ihaskell.pdf>
>     - Sumit Sahrawat <https://github.com/sumitsahrawat>
>    - Improvements to yesod-devel - urbanslug
>    <https://github.com/urbanslug>
>    - Implement nix-like package management features in cabal
>    <https://gist.github.com/fugyk/37510958b52589737274> - Vishal Agrawal
>    <https://github.com/fugyk>
>    - Haddock improvements - ?ukasz Hanuszczak <https://github.com/mrhania>
>
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/50a4f840/attachment.html>

From agocorona at gmail.com  Thu Sep 17 14:01:53 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 17 Sep 2015 16:01:53 +0200
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <55FAC30A.9020005@mansionfamily.plus.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
 <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
 <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>
 <CAKFCL4UNrP_LHJqBU+CUaTfpRRkOGngh51G2GcL8vxA9+Bv=7g@mail.gmail.com>
 <55FAC30A.9020005@mansionfamily.plus.com>
Message-ID: <CAArEJmaQDpjJEOW9x=9B77ReEzPcen3M423BxBQHrde8Abvt9g@mail.gmail.com>

It seems that hPutBuffNonBlocking flush the buffer and blocks anyway when
it has not enough space for the next message.


    -- else, we have to flush        else do debugIO
<https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Internals.html#debugIO>
"hPutBuf: flushing first"                old_buf'
<https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text.html#local-1627606595>
<- Buffered.flushWriteBuffer
<https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer>
haDevice <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text.html#local-1627606575>
old_buf <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text.html#local-1627606591>
                       -- TODO: we should do a non-blocking flush here


https://tldrify.com/bga

this should be a bug or a feature not implemented.

since the flush uses flushWriteBuffer
<https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer>,
that blocks,  hPutBuffNonBlocking does the same than hPutBuff and the
buffer congestion can not be detected.

I will try to do a new version with flushWriteBuffer0
<https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer0>
 which
do not blocks.

2015-09-17 15:41 GMT+02:00 james <james at mansionfamily.plus.com>:

> On 17/09/2015 13:52, Brandon Allbery wrote:
>
>> ...
>> It is possible that recent network package changed this, but in the past
>> *all* socket operations had to be under the aegis of *one* withSocketsDo,
>> otherwise any handles, buffers, etc. would become invalid when Winsock was
>> deinitialized.
>>
>
> See
> http://neilmitchell.blogspot.co.uk/2015/02/making-withsocketsdo-unnecessary.html
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/037a631e/attachment.html>

From allbery.b at gmail.com  Thu Sep 17 14:04:58 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 17 Sep 2015 10:04:58 -0400
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <CAArEJmaQDpjJEOW9x=9B77ReEzPcen3M423BxBQHrde8Abvt9g@mail.gmail.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
 <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
 <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>
 <CAKFCL4UNrP_LHJqBU+CUaTfpRRkOGngh51G2GcL8vxA9+Bv=7g@mail.gmail.com>
 <55FAC30A.9020005@mansionfamily.plus.com>
 <CAArEJmaQDpjJEOW9x=9B77ReEzPcen3M423BxBQHrde8Abvt9g@mail.gmail.com>
Message-ID: <CAKFCL4ULAqo9O9QYQ6__VaHRkYri7ZQODiu4GVXzUP-uBbSSbA@mail.gmail.com>

On Thu, Sep 17, 2015 at 10:01 AM, Alberto G. Corona <agocorona at gmail.com>
wrote:

> since the flush uses flushWriteBuffer
> <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer>
>
> , that blocks,  hPutBuffNonBlocking does the same than hPutBuff and the
> buffer congestion can not be detected.
>

Hm. I wonder if this is the DynamicLog bug we've been fighting with in
xmonad, too. (pipe full -> xmonad locks up, blocked on pipe write)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/89e9d16a/attachment.html>

From agocorona at gmail.com  Thu Sep 17 14:08:28 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 17 Sep 2015 16:08:28 +0200
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <CAKFCL4ULAqo9O9QYQ6__VaHRkYri7ZQODiu4GVXzUP-uBbSSbA@mail.gmail.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
 <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
 <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>
 <CAKFCL4UNrP_LHJqBU+CUaTfpRRkOGngh51G2GcL8vxA9+Bv=7g@mail.gmail.com>
 <55FAC30A.9020005@mansionfamily.plus.com>
 <CAArEJmaQDpjJEOW9x=9B77ReEzPcen3M423BxBQHrde8Abvt9g@mail.gmail.com>
 <CAKFCL4ULAqo9O9QYQ6__VaHRkYri7ZQODiu4GVXzUP-uBbSSbA@mail.gmail.com>
Message-ID: <CAArEJmb9oVyQ4RY+4PVxSRuFGE4fBatCZYyEqb4bZt3ZP=TTwg@mail.gmail.com>

It could be, since this module is general for any kind of buffered IO


2015-09-17 16:04 GMT+02:00 Brandon Allbery <allbery.b at gmail.com>:

> On Thu, Sep 17, 2015 at 10:01 AM, Alberto G. Corona <agocorona at gmail.com>
> wrote:
>
>> since the flush uses flushWriteBuffer
>> <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer>
>>
>> , that blocks,  hPutBuffNonBlocking does the same than hPutBuff and the
>> buffer congestion can not be detected.
>>
>
> Hm. I wonder if this is the DynamicLog bug we've been fighting with in
> xmonad, too. (pipe full -> xmonad locks up, blocked on pipe write)
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/0f5d2584/attachment.html>

From agocorona at gmail.com  Thu Sep 17 17:17:19 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 17 Sep 2015 19:17:19 +0200
Subject: [Haskell-cafe] test socket buffer full
In-Reply-To: <CAArEJmb9oVyQ4RY+4PVxSRuFGE4fBatCZYyEqb4bZt3ZP=TTwg@mail.gmail.com>
References: <CAArEJmYKzs5x91dW72_DynCPKCLhUSmhqnq2hrKjHNWFS93UqA@mail.gmail.com>
 <CAKFCL4WiOP1-Nd=-RdgjK73Pr8vzLh9mYG9q1BLRj7rDb4XdXQ@mail.gmail.com>
 <CAArEJmbfd3maxH+UeVuRMxaheSxFCr6vdjeuHyjSZAZe6maFNA@mail.gmail.com>
 <CAKFCL4UNrP_LHJqBU+CUaTfpRRkOGngh51G2GcL8vxA9+Bv=7g@mail.gmail.com>
 <55FAC30A.9020005@mansionfamily.plus.com>
 <CAArEJmaQDpjJEOW9x=9B77ReEzPcen3M423BxBQHrde8Abvt9g@mail.gmail.com>
 <CAKFCL4ULAqo9O9QYQ6__VaHRkYri7ZQODiu4GVXzUP-uBbSSbA@mail.gmail.com>
 <CAArEJmb9oVyQ4RY+4PVxSRuFGE4fBatCZYyEqb4bZt3ZP=TTwg@mail.gmail.com>
Message-ID: <CAArEJmYu5VFH+g_GHEtbtzbpMbBiJojgSjX9y+2vrZu21HG4XA@mail.gmail.com>

I came up with this implementation below, that  theoretically flush the
buffer non blocking



hPutBufNonBlocking handle ptr count
  | count == 0 = return 0
  | count <  0 = error "negative chunk size"
  | otherwise =
    wantWritableHandle "hPutBuf" handle $
      \ h_ at Handle__{..} -> bufWriteNonBlocking h_ (castPtr ptr) count False



bufWriteNonBlocking :: Handle__-> Ptr Word8 -> Int -> Bool -> IO Int
bufWriteNonBlocking h_ at Handle__{..} ptr count can_block =
  seq count $ do  -- strictness hack
  old_buf at Buffer{  bufR=w, bufSize=size }  <- readIORef haByteBuffer
  -- print (size,w, count)
  old_buf'@Buffer{  bufR=w', bufSize = size' } <-
        if size - w <= count
          then   do
            (written,old_buf') <- Buffered.flushWriteBuffer0 haDevice
old_buf
            writeIORef haByteBuffer old_buf'
            print (size , written,w, count)
            print (bufSize old_buf', bufR old_buf')
            return old_buf'
          else return old_buf

  let count'= if size' - w' > count then count else size' - w'
  writeChunkNonBlocking h_ (castPtr ptr) count'
  writeIORef haByteBuffer old_buf'{ bufR = w' + count' }

  return count'



writeChunkNonBlocking h_ at Handle__{..} ptr bytes
  | Just fd <- cast haDevice  =  RawIO.writeNonBlocking (fd::FD) ptr bytes
  | otherwise = error "Todo: hPutBuf"

But:

flushWriteBuffer0
<http://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer0>
 :: dev
<http://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#local-1627535594>
 -> Buffer
<http://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Buffer.html#Buffer>
 Word8
<http://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Word.html#Word8>
 -> IO (Int, Buffer
<http://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Buffer.html#Buffer>
 Word8
<http://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Word.html#Word8>
)

-- | Flush data from the supplied write buffer out to the device  --
without blocking.  Returns the number of bytes written and the  --
remaining buffer.

should flush  the send buffer as much as possible without waiting for
enough available space in the device/receiving side to empty the send buffer

but it blocks as well (at least using sockets), and waits until the whole
send buffer is emptied, just like ffunshWriteBuffer.

So it is not possible for the application to know if both buffers are
full.  It can be ckecked if the send buffer is full before flushing, but
the device buffers and the receiving buffer may be  empty, and the
receiving process idle. In the other side, if the buffer is flushed, since
it blocks, the send buffer will appear empty after blocking for some time.
So the process can do nothing to detect the congestion condition and it
will be non responsive to other events.

Can fusshWriteBuffer0 and hPutBufNonBlocking be fixed?

2015-09-17 16:08 GMT+02:00 Alberto G. Corona <agocorona at gmail.com>:

> It could be, since this module is general for any kind of buffered IO
>
>
> 2015-09-17 16:04 GMT+02:00 Brandon Allbery <allbery.b at gmail.com>:
>
>> On Thu, Sep 17, 2015 at 10:01 AM, Alberto G. Corona <agocorona at gmail.com>
>> wrote:
>>
>>> since the flush uses flushWriteBuffer
>>> <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer>
>>>
>>> , that blocks,  hPutBuffNonBlocking does the same than hPutBuff and the
>>> buffer congestion can not be detected.
>>>
>>
>> Hm. I wonder if this is the DynamicLog bug we've been fighting with in
>> xmonad, too. (pipe full -> xmonad locks up, blocked on pipe write)
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>
>
> --
> Alberto.
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/0e048dfc/attachment.html>

From david.feuer at gmail.com  Thu Sep 17 18:21:28 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 17 Sep 2015 14:21:28 -0400
Subject: [Haskell-cafe] Replication class
In-Reply-To: <CAMgWh9ukZfcSTGLp2fXi2H_RkGzGhoGQ_jLk48Z5Lvc1WCswmw@mail.gmail.com>
References: <CAMgWh9ukZfcSTGLp2fXi2H_RkGzGhoGQ_jLk48Z5Lvc1WCswmw@mail.gmail.com>
Message-ID: <CAMgWh9udU6QYAHFo9yB33FDCh3TXtV95ckg+VpfBs6OD6PZkvg@mail.gmail.com>

A number of types support some version of replication. Lists and vectors
offer replicateM, while sequences have replicateA (the same thing, but
generalized to Applicative). Is there, or should there be, a class for
structures that support this operation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/e471375f/attachment.html>

From svenpanne at gmail.com  Thu Sep 17 19:09:52 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 17 Sep 2015 21:09:52 +0200
Subject: [Haskell-cafe] Linking to anchors in Haddock
Message-ID: <CANBN=mtGw+n=qZAimq2-d-u_qRmtbXPTX2G9LHT0+r9AN+vvWQ@mail.gmail.com>

Haddock offers a way to add anchors to the documentation and to link to
them, see
https://www.haskell.org/haddock/doc/html/ch03s08.html#idm140354810720016.
I've got 2 problems with that:

   * A link to an anchor "Foo.Bar#Baz" is always rendered with the text
"Foo.Bar" in the HTML backend. Is there a way to change that? With the HTML
backend I actually want something like:

        <a href="path-to-Foo.Bar#Baz">My own link text</a>

   * Using relative hype [My own link text](Foo-Bar.html#Baz) instead has
problems, too: The "Foo-Bar.html" part is fragile and depends on Haddock
flags. Furthermore, when using the LaTeX backend, the resulting LaTeX code
is broken (the '#' needs an escaping backslash).

So is there a non-fragile way working with several backends which makes it
possible to specify the link text? Staring at the Haddock docs and the
Haddock source code didn't help, and several experiments gave no clue,
either. :-/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/8d2daab3/attachment.html>

From svenpanne at gmail.com  Thu Sep 17 19:10:22 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 17 Sep 2015 21:10:22 +0200
Subject: [Haskell-cafe] Anchors in Haddock
Message-ID: <CANBN=mtDiWBmML2jR_bkgTtyricofNKX8+rvvNqpMzxZA7Zr9w@mail.gmail.com>

Haddock offers a way to add anchors to the documentation and to link to
them, see
https://www.haskell.org/haddock/doc/html/ch03s08.html#idm140354810720016.
I've got
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/32f4b7fb/attachment.html>

From svenpanne at gmail.com  Thu Sep 17 19:12:00 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 17 Sep 2015 21:12:00 +0200
Subject: [Haskell-cafe] Anchors in Haddock
In-Reply-To: <CANBN=mtDiWBmML2jR_bkgTtyricofNKX8+rvvNqpMzxZA7Zr9w@mail.gmail.com>
References: <CANBN=mtDiWBmML2jR_bkgTtyricofNKX8+rvvNqpMzxZA7Zr9w@mail.gmail.com>
Message-ID: <CANBN=mu7DqXi4WwGBYbLfzgU6oKLOHWZFCpta=4EkvQiM+QHMw@mail.gmail.com>

[ Sorry, gmail somehow decided to send this incomplete mail... :-P ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/882d6519/attachment.html>

From lists at andy-morris.xyz  Thu Sep 17 23:49:33 2015
From: lists at andy-morris.xyz (Andrew Morris)
Date: Fri, 18 Sep 2015 00:49:33 +0100
Subject: [Haskell-cafe] Replication class
In-Reply-To: <CAMgWh9udU6QYAHFo9yB33FDCh3TXtV95ckg+VpfBs6OD6PZkvg@mail.gmail.com>
References: <CAMgWh9ukZfcSTGLp2fXi2H_RkGzGhoGQ_jLk48Z5Lvc1WCswmw@mail.gmail.com>
 <CAMgWh9udU6QYAHFo9yB33FDCh3TXtV95ckg+VpfBs6OD6PZkvg@mail.gmail.com>
Message-ID: <BE9BBCA3-E077-4990-AB25-94C93FED010D@andy-morris.xyz>

mono-traversable has Data.Sequences.IsSequence, but it ?should be considered highly experimental?.

http://hackage.haskell.org/package/mono-traversable/docs/Data-Sequences.html

> On 17 Sep 2015, at 19:21, David Feuer <david.feuer at gmail.com> wrote:
> 
> A number of types support some version of replication. Lists and vectors offer replicateM, while sequences have replicateA (the same thing, but generalized to Applicative). Is there, or should there be, a class for structures that support this operation?
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From david.feuer at gmail.com  Fri Sep 18 00:54:52 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 17 Sep 2015 20:54:52 -0400
Subject: [Haskell-cafe] Replication class
In-Reply-To: <BE9BBCA3-E077-4990-AB25-94C93FED010D@andy-morris.xyz>
References: <CAMgWh9ukZfcSTGLp2fXi2H_RkGzGhoGQ_jLk48Z5Lvc1WCswmw@mail.gmail.com>
 <CAMgWh9udU6QYAHFo9yB33FDCh3TXtV95ckg+VpfBs6OD6PZkvg@mail.gmail.com>
 <BE9BBCA3-E077-4990-AB25-94C93FED010D@andy-morris.xyz>
Message-ID: <CAMgWh9sZ5p-PpuSEGDcQ_xk26qdv9TD+siCyTxKVN1iHaROi6Q@mail.gmail.com>

That class has a lot of other things in it too, and does not offer
replicateA.
On Sep 17, 2015 7:49 PM, "Andrew Morris" <lists at andy-morris.xyz> wrote:

> mono-traversable has Data.Sequences.IsSequence, but it ?should be
> considered highly experimental?.
>
>
> http://hackage.haskell.org/package/mono-traversable/docs/Data-Sequences.html
>
> > On 17 Sep 2015, at 19:21, David Feuer <david.feuer at gmail.com> wrote:
> >
> > A number of types support some version of replication. Lists and vectors
> offer replicateM, while sequences have replicateA (the same thing, but
> generalized to Applicative). Is there, or should there be, a class for
> structures that support this operation?
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150917/3674787e/attachment-0001.html>

From kyle.marek.spartz at gmail.com  Fri Sep 18 01:23:33 2015
From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz)
Date: Thu, 17 Sep 2015 20:23:33 -0500
Subject: [Haskell-cafe] Looking for better than Dragon Book
In-Reply-To: <CAEzeKYp53sdO8BEqKgS3XrZhRPQkhNyKtd7-HeWGghHDGz2WHQ@mail.gmail.com>
References: <CAEzeKYp53sdO8BEqKgS3XrZhRPQkhNyKtd7-HeWGghHDGz2WHQ@mail.gmail.com>
Message-ID: <2fcp3s7fnoy0yy.fsf@gmail.com>

It's not a "book", but there is the Kaleidoscope LLVM tutorial ported to
Haskell:

https://github.com/sdiehl/kaleidoscope

http://www.stephendiehl.com/llvm/

Michael Litchard writes:

> I've got the Tiger Book, ML version, which I will use to help me implement
> Tiger in Haskell.
> Below is a class curriculum I've found. But besides the Tiger Book, it uses
> the Dragon Book. I know there are more modern books out there. Looking for
> suggestions as what might be a good fit.
>
>
> http://cs.nyu.edu/courses/fall13/CSCI-GA.2130-001/
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

--
Kyle Marek-Spartz

From ollie at ocharles.org.uk  Fri Sep 18 10:32:58 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Fri, 18 Sep 2015 10:32:58 +0000
Subject: [Haskell-cafe] London Haskell eXchange & Haskell Infrastructure
	Hackathon
Message-ID: <CAGRp5R=bWQUP3HaED8cGXNpEGdkBbqzjRbid3yCiOHs5TUbaYA@mail.gmail.com>

Hi all,

In October Skills Matter & Well-Typed are organising a few Haskell events
in London that will (I expect!) be of interest to people here.

On the 8-9th of October is the Haskell eXchange, a 2-day conference on
various topics about Haskell. The programme includes a variety of topics
from the theoretical to the practical, with a mixture of talks, keynotes,
lightning talks and workshop. A promo-code is valid until Sept 19th for 25%
off - use HASKELL-EXCHANGE-25. For more details and booking, see
https://skillsmatter.com/conferences/7069-haskell-exchange-2015.

Shortly after the Haskell eXchange, Well-Typed will co-organize and
participate in a two-day Haskell Hackathon
<https://skillsmatter.com/conferences/7316-haskell-hackathon-2015>, which
takes place directly after the Haskell eXchange, 10-11th October.

This Hackathon aims at bringing together Haskell developers ? both
beginners and experts ? who want to help improve the Haskell
infrastructure, predominantly Hackage and Cabal.

We?ll aim to arrange some introductory overview talks, to e.g. provide an
overview over the code bases and the most important open issues.

Participation is free, but please register online:
https://skillsmatter.com/conferences/7316-haskell-hackathon-2015.

Hope to see you there!
ocharles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150918/9acf1e76/attachment.html>

From haskell at dshevchenko.biz  Fri Sep 18 15:28:18 2015
From: haskell at dshevchenko.biz (Denis Shevchenko)
Date: Fri, 18 Sep 2015 18:28:18 +0300
Subject: [Haskell-cafe] ghc-mod-5.4.0.0 and stack
In-Reply-To: <2fcp3s7fnoy0yy.fsf@gmail.com>
References: <CAEzeKYp53sdO8BEqKgS3XrZhRPQkhNyKtd7-HeWGghHDGz2WHQ@mail.gmail.com>
 <2fcp3s7fnoy0yy.fsf@gmail.com>
Message-ID: <55FC2D92.3010000@dshevchenko.biz>

Hi!

I try to use last ghc-mod with stack. In Changelog 
(https://hackage.haskell.org/package/ghc-mod-5.4.0.0/changelog) I read:

* Add support for the Stack build tool

And I see new option:

     --with-stack=PATH
         stack executable to use

So I do:

$ ghc-mod --with-stack=/usr/local/bin/stack check src/Main.hs

But I got this error:

ghc-mod: cabal: readCreateProcess: runInteractiveProcess: exec: does not 
exist (No such file or directory)

I don't understand it. If I specify path to stack - why ghc-mod still 
try to use cabal-install? And if cabal-install is still required - why 
is this new option for??

- Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150918/b5d65038/attachment.html>

From mantkiew at gsd.uwaterloo.ca  Fri Sep 18 15:36:42 2015
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Fri, 18 Sep 2015 11:36:42 -0400
Subject: [Haskell-cafe] ghc-mod-5.4.0.0 and stack
In-Reply-To: <55FC2D92.3010000@dshevchenko.biz>
References: <CAEzeKYp53sdO8BEqKgS3XrZhRPQkhNyKtd7-HeWGghHDGz2WHQ@mail.gmail.com>
 <2fcp3s7fnoy0yy.fsf@gmail.com> <55FC2D92.3010000@dshevchenko.biz>
Message-ID: <CAGW9QSwWW5D6LPFbnPCmT-Yd6dOvXxfUGmu1Kz+1RuHU9qiOag@mail.gmail.com>

In the ANN announcement email [1] it says:

"* Stack support

  After countless requests ghc-mod now finally has first class Stack
  support. This should mostly Just-Work^TM there is one caveat though if
  `dist/setup-config` exists in a Cabal-project directory ghc-mod will
continue
  using cabal-install instead of Stack so if you want to use Stack instead
  simply remove that file or the whole directory. You also need at least
Stack
  version 0.1.4.0 for this to work."

Micha?

[1]
https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121412.html

On Fri, Sep 18, 2015 at 11:28 AM, Denis Shevchenko <haskell at dshevchenko.biz>
wrote:

> Hi!
>
> I try to use last ghc-mod with stack. In Changelog (
> https://hackage.haskell.org/package/ghc-mod-5.4.0.0/changelog) I read:
>
> * Add support for the Stack build tool
>
> And I see new option:
>
>     --with-stack=PATH
>         stack executable to use
>
> So I do:
>
> $ ghc-mod --with-stack=/usr/local/bin/stack check src/Main.hs
>
> But I got this error:
>
> ghc-mod: cabal: readCreateProcess: runInteractiveProcess: exec: does not
> exist (No such file or directory)
>
> I don't understand it. If I specify path to stack - why ghc-mod still try
> to use cabal-install? And if cabal-install is still required - why is this
> new option for??
>
> - Denis
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150918/99a99515/attachment.html>

From haskell at dshevchenko.biz  Fri Sep 18 16:37:31 2015
From: haskell at dshevchenko.biz (Denis Shevchenko)
Date: Fri, 18 Sep 2015 19:37:31 +0300
Subject: [Haskell-cafe] ghc-mod-5.4.0.0 and stack
In-Reply-To: <CAGW9QSwWW5D6LPFbnPCmT-Yd6dOvXxfUGmu1Kz+1RuHU9qiOag@mail.gmail.com>
References: <CAEzeKYp53sdO8BEqKgS3XrZhRPQkhNyKtd7-HeWGghHDGz2WHQ@mail.gmail.com>
 <2fcp3s7fnoy0yy.fsf@gmail.com> <55FC2D92.3010000@dshevchenko.biz>
 <CAGW9QSwWW5D6LPFbnPCmT-Yd6dOvXxfUGmu1Kz+1RuHU9qiOag@mail.gmail.com>
Message-ID: <55FC3DCB.1030105@dshevchenko.biz>

Thank you very much!

On 18/09/15 18:36, Michal Antkiewicz wrote:
> In the ANN announcement email [1] it says:
>
> "* Stack support
>
>   After countless requests ghc-mod now finally has first class Stack
>   support. This should mostly Just-Work^TM there is one caveat though if
>   `dist/setup-config` exists in a Cabal-project directory ghc-mod will 
> continue
>   using cabal-install instead of Stack so if you want to use Stack instead
>   simply remove that file or the whole directory. You also need at 
> least Stack
>   version 0.1.4.0 for this to work."
>
> Micha?
>
> [1] 
> https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121412.html
>
> On Fri, Sep 18, 2015 at 11:28 AM, Denis Shevchenko 
> <haskell at dshevchenko.biz <mailto:haskell at dshevchenko.biz>> wrote:
>
>     Hi!
>
>     I try to use last ghc-mod with stack. In Changelog
>     (https://hackage.haskell.org/package/ghc-mod-5.4.0.0/changelog) I
>     read:
>
>     * Add support for the Stack build tool
>
>     And I see new option:
>
>         --with-stack=PATH
>             stack executable to use
>
>     So I do:
>
>     $ ghc-mod --with-stack=/usr/local/bin/stack check src/Main.hs
>
>     But I got this error:
>
>     ghc-mod: cabal: readCreateProcess: runInteractiveProcess: exec:
>     does not exist (No such file or directory)
>
>     I don't understand it. If I specify path to stack - why ghc-mod
>     still try to use cabal-install? And if cabal-install is still
>     required - why is this new option for??
>
>     - Denis
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150918/05feb87e/attachment.html>

From miroslav.karpis at gmail.com  Fri Sep 18 22:05:18 2015
From: miroslav.karpis at gmail.com (miro)
Date: Sat, 19 Sep 2015 00:05:18 +0200
Subject: [Haskell-cafe] persistent sqlite: getting record by ID
Message-ID: <89E5C4D0-DE46-4992-B323-FC90F4E679B6@gmail.com>

Please, can you help me with following?

I?m trying to get a record from sqlite by id. I have found following peace of code,?but I?m missing the place that where can I specify the table I?m actually querying (like PersonId).

get $ Key $ (PersistInt64 $ fromIntegral id)


Cheers,
Miro




From rasen.dubi at gmail.com  Sat Sep 19 01:28:53 2015
From: rasen.dubi at gmail.com (Alexey Shmalko)
Date: Sat, 19 Sep 2015 04:28:53 +0300
Subject: [Haskell-cafe] persistent sqlite: getting record by ID
In-Reply-To: <89E5C4D0-DE46-4992-B323-FC90F4E679B6@gmail.com>
References: <89E5C4D0-DE46-4992-B323-FC90F4E679B6@gmail.com>
Message-ID: <CAFC2PC6ALPKKTGWJVcbP_-hkmvGNAeuOXAMNt4wq10n52cmWOQ@mail.gmail.com>

I'm not a persistent user, but as far as I know persistent uses
typeclasses to select appropriate table. According to the yesod
book[1], it seems to be PersistEntity[2] class, precisely it's
entityDef method (see source of getTableName[3] function).

Hope this helps,
Alexey

[1]: http://www.yesodweb.com/book/persistent
[2]: http://hackage.haskell.org/package/persistent-2.2/docs/Database-Persist-Class.html#g:5
[3]: http://hackage.haskell.org/package/persistent-2.2/docs/src/Database-Persist-Sql-Orphan-PersistStore.html#getTableName

On Sat, Sep 19, 2015 at 1:05 AM, miro <miroslav.karpis at gmail.com> wrote:
> Please, can you help me with following?
>
> I?m trying to get a record from sqlite by id. I have found following peace of code,?but I?m missing the place that where can I specify the table I?m actually querying (like PersonId).
>
> get $ Key $ (PersistInt64 $ fromIntegral id)
>
>
> Cheers,
> Miro
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From david.feuer at gmail.com  Sat Sep 19 05:25:00 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 19 Sep 2015 01:25:00 -0400
Subject: [Haskell-cafe] MonadPlus and Alternative folds
Message-ID: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>

It kind of seems like there should be fold-like things to match some and
many.

foldrAlt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
foldrAlt c n m = foldr1Alt c n m <|> pure n

foldr1Alt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
foldr1Alt c n m = c <$> m <*> foldrAlt c n m

foldlMP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
foldlMP' f b m = foldl1MP' f b m <|> pure b

foldl1MP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
foldl1MP' f b m = m >>= \r -> let !b' = f b r in foldlMP' f b' m

--These look a bit iffy
foldlAlt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
foldlAlt f b m = ($ b) <$> foldrAlt (\x r acc -> r (f acc x)) id m

foldl1Alt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
foldl1Alt f b m = ($ b) <$> foldr1Alt (\x r acc -> r (f acc x)) id m

Do these or similar exist somewhere? If not, should they exist somewhere?
I'm particularly interested in whether either of these will be fast, or
will admit a fast implementation, for attoparsec parsers.

Thanks,

David Feuer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150919/03684a8f/attachment.html>

From j at dannynavarro.net  Sat Sep 19 07:22:08 2015
From: j at dannynavarro.net (Danny Navarro)
Date: Sat, 19 Sep 2015 09:22:08 +0200
Subject: [Haskell-cafe] MonadPlus and Alternative folds
In-Reply-To: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
References: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
Message-ID: <CAMO1vvQyiHbZwoiaz6g+o0EYGtM6g5XNxaWHm=fFv=kP6f4PoA@mail.gmail.com>

Not sure about performance, but you could wrap the `Alternative` with
an `Alt`[1] and use the `Foldable` instance.

There is also `Alternative` folding in the `reducers` package.

[1]: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Monoid.html#t:Alt
[2]: https://hackage.haskell.org/package/reducers-3.12.1/docs/Data-Semigroup-Alternative.html

On Sat, Sep 19, 2015 at 7:25 AM, David Feuer <david.feuer at gmail.com> wrote:
> It kind of seems like there should be fold-like things to match some and
> many.
>
> foldrAlt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> foldrAlt c n m = foldr1Alt c n m <|> pure n
>
> foldr1Alt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> foldr1Alt c n m = c <$> m <*> foldrAlt c n m
>
> foldlMP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
> foldlMP' f b m = foldl1MP' f b m <|> pure b
>
> foldl1MP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
> foldl1MP' f b m = m >>= \r -> let !b' = f b r in foldlMP' f b' m
>
> --These look a bit iffy
> foldlAlt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
> foldlAlt f b m = ($ b) <$> foldrAlt (\x r acc -> r (f acc x)) id m
>
> foldl1Alt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
> foldl1Alt f b m = ($ b) <$> foldr1Alt (\x r acc -> r (f acc x)) id m
>
> Do these or similar exist somewhere? If not, should they exist somewhere?
> I'm particularly interested in whether either of these will be fast, or will
> admit a fast implementation, for attoparsec parsers.
>
> Thanks,
>
> David Feuer
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Danny Navarro  |  http://dannynavarro.net

From david.feuer at gmail.com  Sat Sep 19 08:37:53 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 19 Sep 2015 04:37:53 -0400
Subject: [Haskell-cafe] MonadPlus and Alternative folds
In-Reply-To: <CAMO1vvQyiHbZwoiaz6g+o0EYGtM6g5XNxaWHm=fFv=kP6f4PoA@mail.gmail.com>
References: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
 <CAMO1vvQyiHbZwoiaz6g+o0EYGtM6g5XNxaWHm=fFv=kP6f4PoA@mail.gmail.com>
Message-ID: <CAMgWh9v3n+2zF1Y6OEHJv4zsV_HpFff5jDo5j9ULH+sHCLeqPQ@mail.gmail.com>

Alt doesn't have a Foldable instance; these "folds" don't have quite
the right types for that. I don't understand how the reducers relate
to what I'm asking.

On Sat, Sep 19, 2015 at 3:22 AM, Danny Navarro <j at dannynavarro.net> wrote:
> Not sure about performance, but you could wrap the `Alternative` with
> an `Alt`[1] and use the `Foldable` instance.
>
> There is also `Alternative` folding in the `reducers` package.
>
> [1]: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Monoid.html#t:Alt
> [2]: https://hackage.haskell.org/package/reducers-3.12.1/docs/Data-Semigroup-Alternative.html
>
> On Sat, Sep 19, 2015 at 7:25 AM, David Feuer <david.feuer at gmail.com> wrote:
>> It kind of seems like there should be fold-like things to match some and
>> many.
>>
>> foldrAlt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
>> foldrAlt c n m = foldr1Alt c n m <|> pure n
>>
>> foldr1Alt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
>> foldr1Alt c n m = c <$> m <*> foldrAlt c n m
>>
>> foldlMP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
>> foldlMP' f b m = foldl1MP' f b m <|> pure b
>>
>> foldl1MP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
>> foldl1MP' f b m = m >>= \r -> let !b' = f b r in foldlMP' f b' m
>>
>> --These look a bit iffy
>> foldlAlt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
>> foldlAlt f b m = ($ b) <$> foldrAlt (\x r acc -> r (f acc x)) id m
>>
>> foldl1Alt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
>> foldl1Alt f b m = ($ b) <$> foldr1Alt (\x r acc -> r (f acc x)) id m
>>
>> Do these or similar exist somewhere? If not, should they exist somewhere?
>> I'm particularly interested in whether either of these will be fast, or will
>> admit a fast implementation, for attoparsec parsers.
>>
>> Thanks,
>>
>> David Feuer
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Danny Navarro  |  http://dannynavarro.net

From j at dannynavarro.net  Sat Sep 19 08:47:50 2015
From: j at dannynavarro.net (Danny Navarro)
Date: Sat, 19 Sep 2015 10:47:50 +0200
Subject: [Haskell-cafe] MonadPlus and Alternative folds
In-Reply-To: <CAMgWh9v3n+2zF1Y6OEHJv4zsV_HpFff5jDo5j9ULH+sHCLeqPQ@mail.gmail.com>
References: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
 <CAMO1vvQyiHbZwoiaz6g+o0EYGtM6g5XNxaWHm=fFv=kP6f4PoA@mail.gmail.com>
 <CAMgWh9v3n+2zF1Y6OEHJv4zsV_HpFff5jDo5j9ULH+sHCLeqPQ@mail.gmail.com>
Message-ID: <CAMO1vvT=+cSroxYKdFuBtwUZcJtoQsiRf-vC4VFxGvU23hLKKg@mail.gmail.com>

Sorry, you are right, I was thinking about folding `Alt` as a
`Monoid`, but what you need is different.

On Sat, Sep 19, 2015 at 10:37 AM, David Feuer <david.feuer at gmail.com> wrote:
> Alt doesn't have a Foldable instance; these "folds" don't have quite
> the right types for that. I don't understand how the reducers relate
> to what I'm asking.
>
> On Sat, Sep 19, 2015 at 3:22 AM, Danny Navarro <j at dannynavarro.net> wrote:
>> Not sure about performance, but you could wrap the `Alternative` with
>> an `Alt`[1] and use the `Foldable` instance.
>>
>> There is also `Alternative` folding in the `reducers` package.
>>
>> [1]: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Monoid.html#t:Alt
>> [2]: https://hackage.haskell.org/package/reducers-3.12.1/docs/Data-Semigroup-Alternative.html
>>
>> On Sat, Sep 19, 2015 at 7:25 AM, David Feuer <david.feuer at gmail.com> wrote:
>>> It kind of seems like there should be fold-like things to match some and
>>> many.
>>>
>>> foldrAlt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
>>> foldrAlt c n m = foldr1Alt c n m <|> pure n
>>>
>>> foldr1Alt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
>>> foldr1Alt c n m = c <$> m <*> foldrAlt c n m
>>>
>>> foldlMP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
>>> foldlMP' f b m = foldl1MP' f b m <|> pure b
>>>
>>> foldl1MP' :: MonadPlus f => (b -> a -> b) -> b -> f a -> f b
>>> foldl1MP' f b m = m >>= \r -> let !b' = f b r in foldlMP' f b' m
>>>
>>> --These look a bit iffy
>>> foldlAlt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
>>> foldlAlt f b m = ($ b) <$> foldrAlt (\x r acc -> r (f acc x)) id m
>>>
>>> foldl1Alt :: Alternative f => (b -> a -> b) -> b -> f a -> f b
>>> foldl1Alt f b m = ($ b) <$> foldr1Alt (\x r acc -> r (f acc x)) id m
>>>
>>> Do these or similar exist somewhere? If not, should they exist somewhere?
>>> I'm particularly interested in whether either of these will be fast, or will
>>> admit a fast implementation, for attoparsec parsers.
>>>
>>> Thanks,
>>>
>>> David Feuer
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>>
>>
>> --
>> Danny Navarro  |  http://dannynavarro.net



-- 
Danny Navarro  |  http://dannynavarro.net

From ekmett at gmail.com  Sat Sep 19 17:07:17 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 19 Sep 2015 13:07:17 -0400
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
In-Reply-To: <6679B1E7-0987-451E-9C63-DE99562CF1B6@cs.otago.ac.nz>
References: <E32903AD-B72F-41CF-8809-A1CA0CF1FE47@aatal-apotheke.de>
 <55E08229.5050602@gmail.com>
 <CAL3m8eBROcMC4NJb5D4__-E54cwFtw+g969qkAMkrUfMg865PA@mail.gmail.com>
 <A5350E31-553E-44BA-9D66-6DC1B3CFA916@cs.otago.ac.nz>
 <55e53e70.65bd440a.b2a10.ffffe735@mx.google.com>
 <CAD=7U2CioNfMEEahzxzjD=oVg9_ux2RsGV7u20G8WOXmO3r3Dw@mail.gmail.com>
 <55E57E44.90105@unicaen.fr>
 <CAD=7U2CSQVu0Y1uyhL6iVoBphORftnsVNVOqGApXirszRoEL0Q@mail.gmail.com>
 <6679B1E7-0987-451E-9C63-DE99562CF1B6@cs.otago.ac.nz>
Message-ID: <CAJumaK_ug1DgazDJit_0Wg120SHrhUd30wZXfUdRhT3cQc4DiQ@mail.gmail.com>

On Tue, Sep 1, 2015 at 11:23 PM, Richard A. O'Keefe <ok at cs.otago.ac.nz>
wrote:

> And again, nothing stops someone making a nice structured language whose
> compiler targets COBOL.
>
>
It has happened. =)

https://github.com/kadmia/Idris-dev/commit/2ac3c162a082afd83c44add91f8b5b10143bf5d2

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150919/bebc0652/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Sep 19 17:13:18 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 19 Sep 2015 18:13:18 +0100
Subject: [Haskell-cafe] MonadPlus and Alternative folds
In-Reply-To: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
References: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
Message-ID: <20150919171318.GI4299@weber>

On Sat, Sep 19, 2015 at 01:25:00AM -0400, David Feuer wrote:
> It kind of seems like there should be fold-like things to match some and
> many.
> 
> foldrAlt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> foldrAlt c n m = foldr1Alt c n m <|> pure n
> 
> foldr1Alt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> foldr1Alt c n m = c <$> m <*> foldrAlt c n m
[...]

An Alternative allows list-like behaviour when it comes to *construction*,
but offers no operation analogous to pattern-matching and therefore doesn't
allow you to look inside it or do any sort of *destruction*.

I tried foldrAlt and it looped forever, as I expected.  I also expect the
others to loop forever.

Tom

From olf at aatal-apotheke.de  Sat Sep 19 17:27:11 2015
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 19 Sep 2015 19:27:11 +0200
Subject: [Haskell-cafe] MonadPlus and Alternative folds
Message-ID: <B6657DF4-3EBB-4275-9C87-5206ACDFBAE6@aatal-apotheke.de>

Is there an instance of Alternative where some and many are not bottom? The usual example monads, [] and Maybe, don't serve as a source of intuition. 

In general I agree with David: If f is a functor such that every type (f a) is a monoid, then there should be folds. The usual question here is: Your functions have types more general than the known foldr and foldl. Do your functions specialize to the known ones? It seems not. 

For example, foldrAlt (+) 0 [1,2,3] diverges, and so does foldlMP' (+) 0 [1,2,3]. 

I have doubts that knowing how to append two lists gives you access to the recursive structure of a list. Note that mplus is a _constructor_ of lists, while recursion is built on _destructors_. The same seems to apply to all other functions provided by Applicative, Alternative and MonadPlus. The foldr of Data.Foldable, by contrast, accepts a foldable structure and produces something which is not a foldable structure. Hence it must have access to the internals of that foldable structure. 

Olaf

From sven.bartscher at weltraumschlangen.de  Sat Sep 19 17:32:59 2015
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Sat, 19 Sep 2015 19:32:59 +0200
Subject: [Haskell-cafe] MonadPlus and Alternative folds
In-Reply-To: <B6657DF4-3EBB-4275-9C87-5206ACDFBAE6@aatal-apotheke.de>
References: <B6657DF4-3EBB-4275-9C87-5206ACDFBAE6@aatal-apotheke.de>
Message-ID: <ECCC20B8-BAC7-4FC7-8AE0-F0FA2F8571DA@weltraumschlangen.de>


> Am 19.09.2015 um 19:27 schrieb Olaf Klinke <olf at aatal-apotheke.de>:
> 
> Is there an instance of Alternative where some and many are not bottom? The usual example monads, [] and Maybe, don't serve as a source of intuition. 

Parser from optparse-applicative doesn?t give bottom for them. They don?t use the default definition, though.

(I didn?t read anything else of the discussion, but just saw that I know an example for this)

> In general I agree with David: If f is a functor such that every type (f a) is a monoid, then there should be folds. The usual question here is: Your functions have types more general than the known foldr and foldl. Do your functions specialize to the known ones? It seems not. 
> 
> For example, foldrAlt (+) 0 [1,2,3] diverges, and so does foldlMP' (+) 0 [1,2,3]. 
> 
> I have doubts that knowing how to append two lists gives you access to the recursive structure of a list. Note that mplus is a _constructor_ of lists, while recursion is built on _destructors_. The same seems to apply to all other functions provided by Applicative, Alternative and MonadPlus. The foldr of Data.Foldable, by contrast, accepts a foldable structure and produces something which is not a foldable structure. Hence it must have access to the internals of that foldable structure. 
> 
> Olaf
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Sep 19 17:38:47 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 19 Sep 2015 18:38:47 +0100
Subject: [Haskell-cafe] MonadPlus and Alternative folds
In-Reply-To: <20150919171318.GI4299@weber>
References: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
 <20150919171318.GI4299@weber>
Message-ID: <20150919173847.GJ4299@weber>

On Sat, Sep 19, 2015 at 06:13:18PM +0100, Tom Ellis wrote:
> On Sat, Sep 19, 2015 at 01:25:00AM -0400, David Feuer wrote:
> > It kind of seems like there should be fold-like things to match some and
> > many.
> > 
> > foldrAlt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> > foldrAlt c n m = foldr1Alt c n m <|> pure n
> > 
> > foldr1Alt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> > foldr1Alt c n m = c <$> m <*> foldrAlt c n m
> [...]
> 
> An Alternative allows list-like behaviour when it comes to *construction*,
> but offers no operation analogous to pattern-matching and therefore doesn't
> allow you to look inside it or do any sort of *destruction*.
> 
> I tried foldrAlt and it looped forever, as I expected.  I also expect the
> others to loop forever.

I now understand this can work for some Alternatives.  The operational reading
is

1. Try to read an a
2. If it fails, return the b
3. If it succeeds, update the b
4. Go to 1

However, since it doesn't work even for an Alternative as simple as Maybe
it's worth thinking about what class of Alternatives we really want it to
apply to.

Tom

From david.feuer at gmail.com  Sat Sep 19 21:53:40 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 19 Sep 2015 17:53:40 -0400
Subject: [Haskell-cafe] MonadPlus and Alternative folds
In-Reply-To: <20150919173847.GJ4299@weber>
References: <CAMgWh9vgmR6RgVTf4wBtv4=RoJqcodPLN071mN6662ShzX=fyA@mail.gmail.com>
 <20150919171318.GI4299@weber> <20150919173847.GJ4299@weber>
Message-ID: <CAMgWh9tyC--DKa0FviOwiC2AR+Y0K-Qpz6D0-PE0PcGUfijZ_A@mail.gmail.com>

In the case of both Maybe and [], an action that succeeds once will always
succeed. Parsers, other state transformers, and IO don't work like that,
however. I'm not sure where else these apply.
On Sep 19, 2015 1:39 PM, "Tom Ellis" <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> On Sat, Sep 19, 2015 at 06:13:18PM +0100, Tom Ellis wrote:
> > On Sat, Sep 19, 2015 at 01:25:00AM -0400, David Feuer wrote:
> > > It kind of seems like there should be fold-like things to match some
> and
> > > many.
> > >
> > > foldrAlt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> > > foldrAlt c n m = foldr1Alt c n m <|> pure n
> > >
> > > foldr1Alt :: Alternative f => (a -> b -> b) -> b -> f a -> f b
> > > foldr1Alt c n m = c <$> m <*> foldrAlt c n m
> > [...]
> >
> > An Alternative allows list-like behaviour when it comes to
> *construction*,
> > but offers no operation analogous to pattern-matching and therefore
> doesn't
> > allow you to look inside it or do any sort of *destruction*.
> >
> > I tried foldrAlt and it looped forever, as I expected.  I also expect the
> > others to loop forever.
>
> I now understand this can work for some Alternatives.  The operational
> reading
> is
>
> 1. Try to read an a
> 2. If it fails, return the b
> 3. If it succeeds, update the b
> 4. Go to 1
>
> However, since it doesn't work even for an Alternative as simple as Maybe
> it's worth thinking about what class of Alternatives we really want it to
> apply to.
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150919/b093cf67/attachment.html>

From matthewtpickering at gmail.com  Sun Sep 20 14:24:03 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sun, 20 Sep 2015 15:24:03 +0100
Subject: [Haskell-cafe] GSoC Retrospective
In-Reply-To: <CAGW9QSxjUZ_GzE8DBHfBd395Gfv84DORJUXd9SnBPp+g4EWtZA@mail.gmail.com>
References: <51DD782D-3A19-4B12-B8F0-08BFCC2FB35F@steinitz.org>
 <135ECCCB-75D7-42FF-A435-B7234CB8E5BE@steinitz.org>
 <CALuQ0m-THCqs8KpORtfMTfiZ1p08Kw7hfC3-oFUnYYf1Yge0KQ@mail.gmail.com>
 <CAGW9QSxjUZ_GzE8DBHfBd395Gfv84DORJUXd9SnBPp+g4EWtZA@mail.gmail.com>
Message-ID: <CALuQ0m-uFHAYbAC7bvcep9PHV14GNqx1EhbgUPgpRduQFA5E2A@mail.gmail.com>

It is currently a standalone executable. Calling hlint with certain
options causes hlint to then call this executable which performs the
refactoring operations.

On Thu, Sep 17, 2015 at 2:22 PM, Michal Antkiewicz
<mantkiew at gsd.uwaterloo.ca> wrote:
> Matthew, that looks great!
>
> How is the tool going to be distributed? Is it part of something (like
> ghc-mod) or standalone?
>
> Cheers,
> Micha?
>
> On Thu, Sep 17, 2015 at 5:05 AM, Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
>>
>> My project was refactoring programs with hlint suggestions. I'm
>> counting it as a success but I am waiting for a new release of HSE and
>> hlint before making an announcement. We can apply almost all
>> suggestions from hlint.
>>
>> Here is a demo of it working -
>>
>> https://camo.githubusercontent.com/a928338441f119fa911151c0db0ceaa72c51e0c4/687474703a2f2f692e696d6775722e636f6d2f3759586f5666742e676966
>>
>> Matt
>>
>> On Thu, Sep 17, 2015 at 9:18 AM, Dominic Steinitz <dominic at steinitz.org>
>> wrote:
>> > For example, if I look at
>> >
>> > Implementation of Layered Gramamar of Graphics - chinu
>> >
>> >
>> > I see the last commit was made on 30 June and the README says
>> >
>> > Working on a implementation of layered grammar of graphics. Work in
>> > progress, Nothing to see here, Move on.
>> >
>> >
>> > I don?t wish to be judgemental but this rather looks like the goal was
>> > never
>> > achieved?
>> >
>> > Dominic Steinitz
>> > dominic at steinitz.org
>> > http://idontgetoutmuch.wordpress.com
>> >
>> > On 17 Sep 2015, at 09:13, Dominic Steinitz <dominic at steinitz.org> wrote:
>> >
>> > In past years, Gwern did an outstanding job of summarising the GSoC
>> > proposals and how well they had done:
>> > http://www.gwern.net/Haskell%20Summer%20of%20Code
>> >
>> > Here are the proposals for this year. Perhaps students or their mentors
>> > could comment on how successful their projects have been? I realise this
>> > is
>> > a very poor substitute for Gwen?s analyses but it would better than
>> > nothing.
>> >
>> > A Strict language pragma for GHC - Adam Sandberg Eriksson
>> > STM Data Structures Implementation - Alex Semin
>> > Implementation of Layered Gramamar of Graphics - chinu
>> > Implementing Version Comparison for Cabal Packages - Craig Roche
>> > Improving Hackage Discoverability - D. Zack Garza
>> > Darcsden improvements - Daniil Frumin
>> > Pursuit enhancements - Harry Garrood
>> > Improvements For HBLAS And Adding LAPACK Bindings. - JuejiYang
>> > A standalone functional parser for CommonMark - Julien Cretel
>> > Refactor program with HLint suggestions - Matthew Pickering
>> > Replication back-end for acid-state - Max Voit
>> > Native Haskell Type Encoding for LiquidHaskell - Michael Smith
>> > Exhaustiveness Checker for PureScript - Nicolas Del Piano
>> > Fast splittable pseudorandom number generator for System.Random - Nikita
>> > Kartashov
>> > Interactive widgets in IHaskell - Sumit Sahrawat
>> > Improvements to yesod-devel - urbanslug
>> > Implement nix-like package management features in cabal - Vishal Agrawal
>> > Haddock improvements - ?ukasz Hanuszczak
>> >
>> >
>> > Dominic Steinitz
>> > dominic at steinitz.org
>> > http://idontgetoutmuch.wordpress.com
>> >
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> >
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>

From simon at joyful.com  Mon Sep 21 20:33:18 2015
From: simon at joyful.com (Simon Michael)
Date: Mon, 21 Sep 2015 13:33:18 -0700
Subject: [Haskell-cafe] ANN: FunGEn-1.0 - easy-to-install cross-platform
	game engine
Message-ID: <F89BCCAB-B755-4F02-9285-0EB5CD1D8F96@joyful.com>

I'm pleased to announce the release of FunGEn 1.0 !

What is it ?

FunGEn (Functional Game Engine) is the oldest game engine in Haskell.
It was created by Andre Furtado in 2002, has never been used since,
and yet it is arguably still the easiest and most practical way to
make a video game using Haskell. It is BSD-licensed, installs easily
on unix, mac and windows, does not use FRP, and comes with two
playable example games.

What does it do ?

Here's Andre's original feature list:

- Initialization, updating, removing, rendering and grouping
  routines for game objects;

- Definition of a game background (or map), including texture-based
  maps and tile maps;

- Reading and intepretation of the player's keyboard input;

- Collision detection;

- Time-based functions and pre-defined game actions;

- Loading and displaying of 24-bit bitmap files;

- Some debugging and game performance evaluation facilities;

- Sound support (actually for windows platforms only... :-[ )

What's new in 1.0 ?

- supports GHC 7.10

- supports stack

- the repo (and project) has moved to the haskell-game organization on Github

How to install

$ cabal update
$ cabal install FunGEn
# ensure ~/.cabal/bin or windows equiv. is in your PATH

or 

$ git clone https://github.com/haskell-game/fungen
$ cd fungen
$ stack install

How to run the examples

$ fungen-hello
$ fungen-pong
$ fungen-worms

More info

http://hackage.haskell.org/package/FunGEn
https://github.com/haskell-game/fungen
http://joyful.com/fungen - old home page

Why ?

I think FunGEn still has some value, for building games and also as an
example of how to structure games in haskell. I don't have time to do
much with it, so I've moved it to the haskell-game organization, where
all org members now have push access.  I'd like it to be as open as
possible to contributors, and am seeking a new or co- maintainer.

Best,
-Simon (sm on #haskell-game)


From mike at izbicki.me  Tue Sep 22 15:17:18 2015
From: mike at izbicki.me (Mike Izbicki)
Date: Tue, 22 Sep 2015 08:17:18 -0700
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
Message-ID: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>

80% of packages in stackage that contain floating point expressions
have numerically unstable expressions.  The Herbie GHC plugin
automatically makes these expressions numerically stable.

You can find the project on github at:
https://github.com/mikeizbicki/HerbiePlugin

From cma at bitemyapp.com  Tue Sep 22 15:41:47 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 22 Sep 2015 10:41:47 -0500
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
Message-ID: <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>

This is *so cool*. One question - why did you go with something that
modifies the Core instead of rewriting the original source a la Alan
Zimmerman's work? Is it because the stable forms are sometimes gnarly
looking?

Thanks for making and sharing this!

On Tue, Sep 22, 2015 at 10:17 AM, Mike Izbicki <mike at izbicki.me> wrote:

> 80% of packages in stackage that contain floating point expressions
> have numerically unstable expressions.  The Herbie GHC plugin
> automatically makes these expressions numerically stable.
>
> You can find the project on github at:
> https://github.com/mikeizbicki/HerbiePlugin
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/7473966d/attachment.html>

From mike at izbicki.me  Tue Sep 22 15:46:29 2015
From: mike at izbicki.me (Mike Izbicki)
Date: Tue, 22 Sep 2015 08:46:29 -0700
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
Message-ID: <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>

I'm not familiar with Alan Zimmerman's work.  AFAIK, the only way to
get GHC to modify Haskell code without any annotations is via the
plugin mechanism, which manipulates core.  It would have been possible
to do a template haskell quasiquoter, but that would require the
programmer to have to manually annotate their math expressions.  But I
didn't want the programmer to have to do anything at all.

On Tue, Sep 22, 2015 at 8:41 AM, Christopher Allen <cma at bitemyapp.com> wrote:
> This is *so cool*. One question - why did you go with something that
> modifies the Core instead of rewriting the original source a la Alan
> Zimmerman's work? Is it because the stable forms are sometimes gnarly
> looking?
>
> Thanks for making and sharing this!
>
> On Tue, Sep 22, 2015 at 10:17 AM, Mike Izbicki <mike at izbicki.me> wrote:
>>
>> 80% of packages in stackage that contain floating point expressions
>> have numerically unstable expressions.  The Herbie GHC plugin
>> automatically makes these expressions numerically stable.
>>
>> You can find the project on github at:
>> https://github.com/mikeizbicki/HerbiePlugin
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com

From cma at bitemyapp.com  Tue Sep 22 15:48:49 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 22 Sep 2015 10:48:49 -0500
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
 <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
Message-ID: <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>

Oh, I'm thinking of stuff like:
https://hackage.haskell.org/package/ghc-exactprint

Where the idea is the tool would refactor and rewrite your code, putting it
back where it was. Kinda like go fmt, but you can do anything you want.

https://github.com/mpickering/apply-refact also comes to mind.

I guess I'm thinking of this because I think it could be useful for
programmers to preserve the fixed versions in their source code, maybe with
before & after comments, for educational purposes.

On Tue, Sep 22, 2015 at 10:46 AM, Mike Izbicki <mike at izbicki.me> wrote:

> I'm not familiar with Alan Zimmerman's work.  AFAIK, the only way to
> get GHC to modify Haskell code without any annotations is via the
> plugin mechanism, which manipulates core.  It would have been possible
> to do a template haskell quasiquoter, but that would require the
> programmer to have to manually annotate their math expressions.  But I
> didn't want the programmer to have to do anything at all.
>
> On Tue, Sep 22, 2015 at 8:41 AM, Christopher Allen <cma at bitemyapp.com>
> wrote:
> > This is *so cool*. One question - why did you go with something that
> > modifies the Core instead of rewriting the original source a la Alan
> > Zimmerman's work? Is it because the stable forms are sometimes gnarly
> > looking?
> >
> > Thanks for making and sharing this!
> >
> > On Tue, Sep 22, 2015 at 10:17 AM, Mike Izbicki <mike at izbicki.me> wrote:
> >>
> >> 80% of packages in stackage that contain floating point expressions
> >> have numerically unstable expressions.  The Herbie GHC plugin
> >> automatically makes these expressions numerically stable.
> >>
> >> You can find the project on github at:
> >> https://github.com/mikeizbicki/HerbiePlugin
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> >
> >
> >
> > --
> > Chris Allen
> > Currently working on http://haskellbook.com
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/ba47db68/attachment.html>

From eric at seidel.io  Tue Sep 22 15:57:26 2015
From: eric at seidel.io (Eric Seidel)
Date: Tue, 22 Sep 2015 08:57:26 -0700
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
 <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
 <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>
Message-ID: <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>

On Tue, Sep 22, 2015, at 08:48, Christopher Allen wrote:
> I guess I'm thinking of this because I think it could be useful for
> programmers to preserve the fixed versions in their source code, maybe
> with
> before & after comments, for educational purposes.

My thoughts exactly, I think this would be *really* cool as an
HLint-style tool.

From b at chreekat.net  Tue Sep 22 16:08:49 2015
From: b at chreekat.net (Bryan Richter)
Date: Tue, 22 Sep 2015 09:08:49 -0700
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
 <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
 <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>
 <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>
Message-ID: <20150922160849.GA26757@fuzzbomb>

On Tue, Sep 22, 2015 at 08:57:26AM -0700, Eric Seidel wrote:
> On Tue, Sep 22, 2015, at 08:48, Christopher Allen wrote:
> > I guess I'm thinking of this because I think it could be useful
> > for programmers to preserve the fixed versions in their source
> > code, maybe with before & after comments, for educational
> > purposes.
> 
> My thoughts exactly, I think this would be *really* cool as an
> HLint-style tool.

I foresee -fwarn-numeric-instability! This goes beyond nice syntax
suggestions to actually fixing potential bugs (when shared and
compiled by other versions/compilers). Very cool. :)

From mike at izbicki.me  Tue Sep 22 17:17:37 2015
From: mike at izbicki.me (Mike Izbicki)
Date: Tue, 22 Sep 2015 10:17:37 -0700
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
 <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
 <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>
 <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>
Message-ID: <CAKKZoUXxcJWDCMYi40MEo+GRiK_0FwnvgLHCbv1mL5foOyQ-mg@mail.gmail.com>

> My thoughts exactly, I think this would be *really* cool as an HLint-style tool.

The main problem with this is that numerically stable expressions are
often very opaque.  If you look at the first example in the README, I
would definitely rather have:

w far near = -(2 * far * near) / (far - near)

in my code than

w near far = if near < -1.7210442634149447e+81
    then (2.0 * near / (near - far)) * far
    else if near < 8.364504563556443e+16
        then (2.0 * near) / ((near - far) / far)
        else ((2.0 * near) / (near - far)) * far

One of the reasons I use Haskell is because the code is "at the level
of thought" and GHC translates this into awesome speed without the
programmer needing to worry about the gory details in most cases.  I
want that same experience for numerical stability.

From cma at bitemyapp.com  Tue Sep 22 17:19:21 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 22 Sep 2015 12:19:21 -0500
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAKKZoUXxcJWDCMYi40MEo+GRiK_0FwnvgLHCbv1mL5foOyQ-mg@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
 <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
 <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>
 <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>
 <CAKKZoUXxcJWDCMYi40MEo+GRiK_0FwnvgLHCbv1mL5foOyQ-mg@mail.gmail.com>
Message-ID: <CADnndOo-6xDDvFEMvvHE56Kr4yoYO5xJFLGQa6vV2n+78FdiBg@mail.gmail.com>

That's what I suggested might be the case and this makes sense. Thank you :)

On Tue, Sep 22, 2015 at 12:17 PM, Mike Izbicki <mike at izbicki.me> wrote:

> > My thoughts exactly, I think this would be *really* cool as an
> HLint-style tool.
>
> The main problem with this is that numerically stable expressions are
> often very opaque.  If you look at the first example in the README, I
> would definitely rather have:
>
> w far near = -(2 * far * near) / (far - near)
>
> in my code than
>
> w near far = if near < -1.7210442634149447e+81
>     then (2.0 * near / (near - far)) * far
>     else if near < 8.364504563556443e+16
>         then (2.0 * near) / ((near - far) / far)
>         else ((2.0 * near) / (near - far)) * far
>
> One of the reasons I use Haskell is because the code is "at the level
> of thought" and GHC translates this into awesome speed without the
> programmer needing to worry about the gory details in most cases.  I
> want that same experience for numerical stability.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/6108cd56/attachment.html>

From arjenvanweelden at gmail.com  Tue Sep 22 17:27:42 2015
From: arjenvanweelden at gmail.com (Arjen)
Date: Tue, 22 Sep 2015 19:27:42 +0200
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CADnndOo-6xDDvFEMvvHE56Kr4yoYO5xJFLGQa6vV2n+78FdiBg@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
 <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
 <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>
 <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>
 <CAKKZoUXxcJWDCMYi40MEo+GRiK_0FwnvgLHCbv1mL5foOyQ-mg@mail.gmail.com>
 <CADnndOo-6xDDvFEMvvHE56Kr4yoYO5xJFLGQa6vV2n+78FdiBg@mail.gmail.com>
Message-ID: <56018F8E.6020309@gmail.com>

On 22-09-15 19:19, Christopher Allen wrote:
> That's what I suggested might be the case and this makes sense. Thank you :)
>
> On Tue, Sep 22, 2015 at 12:17 PM, Mike Izbicki <mike at izbicki.me
> <mailto:mike at izbicki.me>> wrote:
>
>     > My thoughts exactly, I think this would be *really* cool as an HLint-style tool.
>
>     The main problem with this is that numerically stable expressions are
>     often very opaque.  If you look at the first example in the README, I
>     would definitely rather have:
>
>     w far near = -(2 * far * near) / (far - near)
>
>     in my code than
>
>     w near far = if near < -1.7210442634149447e+81
>          then (2.0 * near / (near - far)) * far
>          else if near < 8.364504563556443e+16
>              then (2.0 * near) / ((near - far) / far)
>              else ((2.0 * near) / (near - far)) * far
>
>     One of the reasons I use Haskell is because the code is "at the level
>     of thought" and GHC translates this into awesome speed without the
>     programmer needing to worry about the gory details in most cases.  I
>     want that same experience for numerical stability.
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com

I'd love it if there was a way to (semi-)automatically add rewrite rules 
to the Haskell program source modules.

That way, it is both automatically applied on subsequent compiles, 
consistent between builds, and transparent what is happening, which 
expressions are unstable and how to fix them manually if desired. 
(Although I understand that rewrite rules are not always triggered?)

Thanks for pointing out this problem in (my) programs and automating a 
solution!

kind regards, Arjen

From ekmett at gmail.com  Tue Sep 22 17:39:08 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 22 Sep 2015 13:39:08 -0400
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
Message-ID: <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>

Very nice!

Now I just need to figure out how to extract the results of these analyses
and see if I can understand and apply them manually to what libraries of
mine are affected, so that folks who won't or can't run this plugin can
derive the benefits.

-Edward

On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me> wrote:

> 80% of packages in stackage that contain floating point expressions
> have numerically unstable expressions.  The Herbie GHC plugin
> automatically makes these expressions numerically stable.
>
> You can find the project on github at:
> https://github.com/mikeizbicki/HerbiePlugin
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/e2ff39ec/attachment.html>

From elliot.cameron at covenanteyes.com  Tue Sep 22 18:08:24 2015
From: elliot.cameron at covenanteyes.com (Elliot Cameron)
Date: Tue, 22 Sep 2015 18:08:24 +0000
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>,
 <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
Message-ID: <1442945308113.72351@covenanteyes.com>

Does GHC HQ consider the possibility of embedding/shipping plugins like this with normal releases?

________________________________
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Edward Kmett <ekmett at gmail.com>
Sent: Tuesday, September 22, 2015 1:39 PM
To: mike at izbicki.me
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] ANN: The Herbie GHC Plugin

Very nice!

Now I just need to figure out how to extract the results of these analyses and see if I can understand and apply them manually to what libraries of mine are affected, so that folks who won't or can't run this plugin can derive the benefits.

-Edward

On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me<mailto:mike at izbicki.me>> wrote:
80% of packages in stackage that contain floating point expressions
have numerically unstable expressions.  The Herbie GHC plugin
automatically makes these expressions numerically stable.

You can find the project on github at:
https://github.com/mikeizbicki/HerbiePlugin
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/65d7169e/attachment.html>

From ekmett at gmail.com  Tue Sep 22 19:08:12 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 22 Sep 2015 15:08:12 -0400
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <1442945308113.72351@covenanteyes.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
 <1442945308113.72351@covenanteyes.com>
Message-ID: <CAJumaK-Bb80BAf5u-5Jo8+UDNto88vKPz0xuyTxn_=+NB8Ao_g@mail.gmail.com>

In this case the primary concern would be that Herbie really needs to have
an install of racket as well to do its job right. Between that and a
database, there are a lot of things that aren't usually involved in a
normal GHC install.

-Edward

On Tue, Sep 22, 2015 at 2:08 PM, Elliot Cameron <
elliot.cameron at covenanteyes.com> wrote:

> Does GHC HQ consider the possibility of embedding/shipping plugins like
> this with normal releases?
> ------------------------------
> *From:* Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of
> Edward Kmett <ekmett at gmail.com>
> *Sent:* Tuesday, September 22, 2015 1:39 PM
> *To:* mike at izbicki.me
> *Cc:* Haskell Cafe
> *Subject:* Re: [Haskell-cafe] ANN: The Herbie GHC Plugin
>
> Very nice!
>
> Now I just need to figure out how to extract the results of these analyses
> and see if I can understand and apply them manually to what libraries of
> mine are affected, so that folks who won't or can't run this plugin can
> derive the benefits.
>
> -Edward
>
> On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me> wrote:
>
>> 80% of packages in stackage that contain floating point expressions
>> have numerically unstable expressions.  The Herbie GHC plugin
>> automatically makes these expressions numerically stable.
>>
>> You can find the project on github at:
>> https://github.com/mikeizbicki/HerbiePlugin
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/f8382ae6/attachment.html>

From ekmett at gmail.com  Tue Sep 22 19:48:57 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 22 Sep 2015 15:48:57 -0400
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAJumaK-Bb80BAf5u-5Jo8+UDNto88vKPz0xuyTxn_=+NB8Ao_g@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
 <1442945308113.72351@covenanteyes.com>
 <CAJumaK-Bb80BAf5u-5Jo8+UDNto88vKPz0xuyTxn_=+NB8Ao_g@mail.gmail.com>
Message-ID: <CAJumaK9UK+0rX48pzq-w6b=M-L6BXgYaG_xpvi01C-8-PDf7tw@mail.gmail.com>

Okay. Having gone through and chewed on a bunch of the optimizations it has
found, I have to say I officially absolutely adore this plugin!

It would be nice if it didn't report 'improved' expressions that are the
same as the original, but everything else about it is amazing.

-Edward

On Tue, Sep 22, 2015 at 3:08 PM, Edward Kmett <ekmett at gmail.com> wrote:

> In this case the primary concern would be that Herbie really needs to have
> an install of racket as well to do its job right. Between that and a
> database, there are a lot of things that aren't usually involved in a
> normal GHC install.
>
> -Edward
>
> On Tue, Sep 22, 2015 at 2:08 PM, Elliot Cameron <
> elliot.cameron at covenanteyes.com> wrote:
>
>> Does GHC HQ consider the possibility of embedding/shipping plugins like
>> this with normal releases?
>> ------------------------------
>> *From:* Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of
>> Edward Kmett <ekmett at gmail.com>
>> *Sent:* Tuesday, September 22, 2015 1:39 PM
>> *To:* mike at izbicki.me
>> *Cc:* Haskell Cafe
>> *Subject:* Re: [Haskell-cafe] ANN: The Herbie GHC Plugin
>>
>> Very nice!
>>
>> Now I just need to figure out how to extract the results of these
>> analyses and see if I can understand and apply them manually to what
>> libraries of mine are affected, so that folks who won't or can't run this
>> plugin can derive the benefits.
>>
>> -Edward
>>
>> On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me> wrote:
>>
>>> 80% of packages in stackage that contain floating point expressions
>>> have numerically unstable expressions.  The Herbie GHC plugin
>>> automatically makes these expressions numerically stable.
>>>
>>> You can find the project on github at:
>>> https://github.com/mikeizbicki/HerbiePlugin
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/47b50f16/attachment.html>

From mike at izbicki.me  Tue Sep 22 20:24:02 2015
From: mike at izbicki.me (Mike Izbicki)
Date: Tue, 22 Sep 2015 13:24:02 -0700
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAJumaK9UK+0rX48pzq-w6b=M-L6BXgYaG_xpvi01C-8-PDf7tw@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
 <1442945308113.72351@covenanteyes.com>
 <CAJumaK-Bb80BAf5u-5Jo8+UDNto88vKPz0xuyTxn_=+NB8Ao_g@mail.gmail.com>
 <CAJumaK9UK+0rX48pzq-w6b=M-L6BXgYaG_xpvi01C-8-PDf7tw@mail.gmail.com>
Message-ID: <CAKKZoUXxry38qEYD+KKpbkpf5yrmWtBe88RmG85yHdzX4ghvvg@mail.gmail.com>

Thanks :)

That's a good suggestion about not calling expressions improved when
they're not.  I've just pushed a new patch to the repo that fixes this
issue.

On Tue, Sep 22, 2015 at 12:48 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Okay. Having gone through and chewed on a bunch of the optimizations it has
> found, I have to say I officially absolutely adore this plugin!
>
> It would be nice if it didn't report 'improved' expressions that are the
> same as the original, but everything else about it is amazing.
>
> -Edward
>
> On Tue, Sep 22, 2015 at 3:08 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>
>> In this case the primary concern would be that Herbie really needs to have
>> an install of racket as well to do its job right. Between that and a
>> database, there are a lot of things that aren't usually involved in a normal
>> GHC install.
>>
>> -Edward
>>
>> On Tue, Sep 22, 2015 at 2:08 PM, Elliot Cameron
>> <elliot.cameron at covenanteyes.com> wrote:
>>>
>>> Does GHC HQ consider the possibility of embedding/shipping plugins like
>>> this with normal releases?
>>>
>>> ________________________________
>>> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Edward
>>> Kmett <ekmett at gmail.com>
>>> Sent: Tuesday, September 22, 2015 1:39 PM
>>> To: mike at izbicki.me
>>> Cc: Haskell Cafe
>>> Subject: Re: [Haskell-cafe] ANN: The Herbie GHC Plugin
>>>
>>> Very nice!
>>>
>>> Now I just need to figure out how to extract the results of these
>>> analyses and see if I can understand and apply them manually to what
>>> libraries of mine are affected, so that folks who won't or can't run this
>>> plugin can derive the benefits.
>>>
>>> -Edward
>>>
>>> On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me> wrote:
>>>>
>>>> 80% of packages in stackage that contain floating point expressions
>>>> have numerically unstable expressions.  The Herbie GHC plugin
>>>> automatically makes these expressions numerically stable.
>>>>
>>>> You can find the project on github at:
>>>> https://github.com/mikeizbicki/HerbiePlugin
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>

From ekmett at gmail.com  Tue Sep 22 20:26:14 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 22 Sep 2015 16:26:14 -0400
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAKKZoUXxry38qEYD+KKpbkpf5yrmWtBe88RmG85yHdzX4ghvvg@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
 <1442945308113.72351@covenanteyes.com>
 <CAJumaK-Bb80BAf5u-5Jo8+UDNto88vKPz0xuyTxn_=+NB8Ao_g@mail.gmail.com>
 <CAJumaK9UK+0rX48pzq-w6b=M-L6BXgYaG_xpvi01C-8-PDf7tw@mail.gmail.com>
 <CAKKZoUXxry38qEYD+KKpbkpf5yrmWtBe88RmG85yHdzX4ghvvg@mail.gmail.com>
Message-ID: <CAJumaK8GhgrkWLVZmPmG5w7TvfWsjuMma1ajeNgKQjucRhKawg@mail.gmail.com>

Another minor complications arises from applying these optimizations to the
original source code. When I do so, they often involve the original
expression as a sub-expression, which it then suggests the original
optimization for, despite the ranges where it is inapplicable not being
available at that call site.

I don't see a good way to handle that except to find a way to tell herbie
the actual range the sub-expression can be applied to through some kind of
source annotation.

-Edward


On Tue, Sep 22, 2015 at 4:24 PM, Mike Izbicki <mike at izbicki.me> wrote:

> Thanks :)
>
> That's a good suggestion about not calling expressions improved when
> they're not.  I've just pushed a new patch to the repo that fixes this
> issue.
>
> On Tue, Sep 22, 2015 at 12:48 PM, Edward Kmett <ekmett at gmail.com> wrote:
> > Okay. Having gone through and chewed on a bunch of the optimizations it
> has
> > found, I have to say I officially absolutely adore this plugin!
> >
> > It would be nice if it didn't report 'improved' expressions that are the
> > same as the original, but everything else about it is amazing.
> >
> > -Edward
> >
> > On Tue, Sep 22, 2015 at 3:08 PM, Edward Kmett <ekmett at gmail.com> wrote:
> >>
> >> In this case the primary concern would be that Herbie really needs to
> have
> >> an install of racket as well to do its job right. Between that and a
> >> database, there are a lot of things that aren't usually involved in a
> normal
> >> GHC install.
> >>
> >> -Edward
> >>
> >> On Tue, Sep 22, 2015 at 2:08 PM, Elliot Cameron
> >> <elliot.cameron at covenanteyes.com> wrote:
> >>>
> >>> Does GHC HQ consider the possibility of embedding/shipping plugins like
> >>> this with normal releases?
> >>>
> >>> ________________________________
> >>> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of
> Edward
> >>> Kmett <ekmett at gmail.com>
> >>> Sent: Tuesday, September 22, 2015 1:39 PM
> >>> To: mike at izbicki.me
> >>> Cc: Haskell Cafe
> >>> Subject: Re: [Haskell-cafe] ANN: The Herbie GHC Plugin
> >>>
> >>> Very nice!
> >>>
> >>> Now I just need to figure out how to extract the results of these
> >>> analyses and see if I can understand and apply them manually to what
> >>> libraries of mine are affected, so that folks who won't or can't run
> this
> >>> plugin can derive the benefits.
> >>>
> >>> -Edward
> >>>
> >>> On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me>
> wrote:
> >>>>
> >>>> 80% of packages in stackage that contain floating point expressions
> >>>> have numerically unstable expressions.  The Herbie GHC plugin
> >>>> automatically makes these expressions numerically stable.
> >>>>
> >>>> You can find the project on github at:
> >>>> https://github.com/mikeizbicki/HerbiePlugin
> >>>> _______________________________________________
> >>>> Haskell-Cafe mailing list
> >>>> Haskell-Cafe at haskell.org
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/5a75f781/attachment.html>

From ekmett at gmail.com  Tue Sep 22 20:27:56 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 22 Sep 2015 16:27:56 -0400
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAJumaK8GhgrkWLVZmPmG5w7TvfWsjuMma1ajeNgKQjucRhKawg@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
 <1442945308113.72351@covenanteyes.com>
 <CAJumaK-Bb80BAf5u-5Jo8+UDNto88vKPz0xuyTxn_=+NB8Ao_g@mail.gmail.com>
 <CAJumaK9UK+0rX48pzq-w6b=M-L6BXgYaG_xpvi01C-8-PDf7tw@mail.gmail.com>
 <CAKKZoUXxry38qEYD+KKpbkpf5yrmWtBe88RmG85yHdzX4ghvvg@mail.gmail.com>
 <CAJumaK8GhgrkWLVZmPmG5w7TvfWsjuMma1ajeNgKQjucRhKawg@mail.gmail.com>
Message-ID: <CAJumaK_3zD2L7-L-077vb4kdqrogaDSbkqS4pby_QRuLW2agxQ@mail.gmail.com>

Alternately: One thing I can do with HLint is hint with module annotations
to ignore certain things. Maybe just a HLint-like hint to tell the
HerbiePlugin to ignore a function would suffice?

-Edward



On Tue, Sep 22, 2015 at 4:26 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Another minor complications arises from applying these optimizations to
> the original source code. When I do so, they often involve the original
> expression as a sub-expression, which it then suggests the original
> optimization for, despite the ranges where it is inapplicable not being
> available at that call site.
>
> I don't see a good way to handle that except to find a way to tell herbie
> the actual range the sub-expression can be applied to through some kind of
> source annotation.
>
> -Edward
>
>
> On Tue, Sep 22, 2015 at 4:24 PM, Mike Izbicki <mike at izbicki.me> wrote:
>
>> Thanks :)
>>
>> That's a good suggestion about not calling expressions improved when
>> they're not.  I've just pushed a new patch to the repo that fixes this
>> issue.
>>
>> On Tue, Sep 22, 2015 at 12:48 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> > Okay. Having gone through and chewed on a bunch of the optimizations it
>> has
>> > found, I have to say I officially absolutely adore this plugin!
>> >
>> > It would be nice if it didn't report 'improved' expressions that are the
>> > same as the original, but everything else about it is amazing.
>> >
>> > -Edward
>> >
>> > On Tue, Sep 22, 2015 at 3:08 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> >>
>> >> In this case the primary concern would be that Herbie really needs to
>> have
>> >> an install of racket as well to do its job right. Between that and a
>> >> database, there are a lot of things that aren't usually involved in a
>> normal
>> >> GHC install.
>> >>
>> >> -Edward
>> >>
>> >> On Tue, Sep 22, 2015 at 2:08 PM, Elliot Cameron
>> >> <elliot.cameron at covenanteyes.com> wrote:
>> >>>
>> >>> Does GHC HQ consider the possibility of embedding/shipping plugins
>> like
>> >>> this with normal releases?
>> >>>
>> >>> ________________________________
>> >>> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of
>> Edward
>> >>> Kmett <ekmett at gmail.com>
>> >>> Sent: Tuesday, September 22, 2015 1:39 PM
>> >>> To: mike at izbicki.me
>> >>> Cc: Haskell Cafe
>> >>> Subject: Re: [Haskell-cafe] ANN: The Herbie GHC Plugin
>> >>>
>> >>> Very nice!
>> >>>
>> >>> Now I just need to figure out how to extract the results of these
>> >>> analyses and see if I can understand and apply them manually to what
>> >>> libraries of mine are affected, so that folks who won't or can't run
>> this
>> >>> plugin can derive the benefits.
>> >>>
>> >>> -Edward
>> >>>
>> >>> On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me>
>> wrote:
>> >>>>
>> >>>> 80% of packages in stackage that contain floating point expressions
>> >>>> have numerically unstable expressions.  The Herbie GHC plugin
>> >>>> automatically makes these expressions numerically stable.
>> >>>>
>> >>>> You can find the project on github at:
>> >>>> https://github.com/mikeizbicki/HerbiePlugin
>> >>>> _______________________________________________
>> >>>> Haskell-Cafe mailing list
>> >>>> Haskell-Cafe at haskell.org
>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> >>>
>> >>>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/da960421/attachment.html>

From ekmett at gmail.com  Tue Sep 22 20:29:00 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 22 Sep 2015 16:29:00 -0400
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <CAJumaK_3zD2L7-L-077vb4kdqrogaDSbkqS4pby_QRuLW2agxQ@mail.gmail.com>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CAJumaK_3JoCk-Mig4Q6S1hk9kEiqGXyMHA19JCNu5esY3jr2xA@mail.gmail.com>
 <1442945308113.72351@covenanteyes.com>
 <CAJumaK-Bb80BAf5u-5Jo8+UDNto88vKPz0xuyTxn_=+NB8Ao_g@mail.gmail.com>
 <CAJumaK9UK+0rX48pzq-w6b=M-L6BXgYaG_xpvi01C-8-PDf7tw@mail.gmail.com>
 <CAKKZoUXxry38qEYD+KKpbkpf5yrmWtBe88RmG85yHdzX4ghvvg@mail.gmail.com>
 <CAJumaK8GhgrkWLVZmPmG5w7TvfWsjuMma1ajeNgKQjucRhKawg@mail.gmail.com>
 <CAJumaK_3zD2L7-L-077vb4kdqrogaDSbkqS4pby_QRuLW2agxQ@mail.gmail.com>
Message-ID: <CAJumaK8uOwFFR45uqA1uvSykWzHaZjEW6rXMo+h9gkOPQ7M_Vg@mail.gmail.com>

Let me switch to filing these as issues rather than spamming your
announcement thread. =)

On Tue, Sep 22, 2015 at 4:27 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Alternately: One thing I can do with HLint is hint with module annotations
> to ignore certain things. Maybe just a HLint-like hint to tell the
> HerbiePlugin to ignore a function would suffice?
>
> -Edward
>
>
>
> On Tue, Sep 22, 2015 at 4:26 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Another minor complications arises from applying these optimizations to
>> the original source code. When I do so, they often involve the original
>> expression as a sub-expression, which it then suggests the original
>> optimization for, despite the ranges where it is inapplicable not being
>> available at that call site.
>>
>> I don't see a good way to handle that except to find a way to tell herbie
>> the actual range the sub-expression can be applied to through some kind of
>> source annotation.
>>
>> -Edward
>>
>>
>> On Tue, Sep 22, 2015 at 4:24 PM, Mike Izbicki <mike at izbicki.me> wrote:
>>
>>> Thanks :)
>>>
>>> That's a good suggestion about not calling expressions improved when
>>> they're not.  I've just pushed a new patch to the repo that fixes this
>>> issue.
>>>
>>> On Tue, Sep 22, 2015 at 12:48 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>> > Okay. Having gone through and chewed on a bunch of the optimizations
>>> it has
>>> > found, I have to say I officially absolutely adore this plugin!
>>> >
>>> > It would be nice if it didn't report 'improved' expressions that are
>>> the
>>> > same as the original, but everything else about it is amazing.
>>> >
>>> > -Edward
>>> >
>>> > On Tue, Sep 22, 2015 at 3:08 PM, Edward Kmett <ekmett at gmail.com>
>>> wrote:
>>> >>
>>> >> In this case the primary concern would be that Herbie really needs to
>>> have
>>> >> an install of racket as well to do its job right. Between that and a
>>> >> database, there are a lot of things that aren't usually involved in a
>>> normal
>>> >> GHC install.
>>> >>
>>> >> -Edward
>>> >>
>>> >> On Tue, Sep 22, 2015 at 2:08 PM, Elliot Cameron
>>> >> <elliot.cameron at covenanteyes.com> wrote:
>>> >>>
>>> >>> Does GHC HQ consider the possibility of embedding/shipping plugins
>>> like
>>> >>> this with normal releases?
>>> >>>
>>> >>> ________________________________
>>> >>> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of
>>> Edward
>>> >>> Kmett <ekmett at gmail.com>
>>> >>> Sent: Tuesday, September 22, 2015 1:39 PM
>>> >>> To: mike at izbicki.me
>>> >>> Cc: Haskell Cafe
>>> >>> Subject: Re: [Haskell-cafe] ANN: The Herbie GHC Plugin
>>> >>>
>>> >>> Very nice!
>>> >>>
>>> >>> Now I just need to figure out how to extract the results of these
>>> >>> analyses and see if I can understand and apply them manually to what
>>> >>> libraries of mine are affected, so that folks who won't or can't run
>>> this
>>> >>> plugin can derive the benefits.
>>> >>>
>>> >>> -Edward
>>> >>>
>>> >>> On Tue, Sep 22, 2015 at 11:17 AM, Mike Izbicki <mike at izbicki.me>
>>> wrote:
>>> >>>>
>>> >>>> 80% of packages in stackage that contain floating point expressions
>>> >>>> have numerically unstable expressions.  The Herbie GHC plugin
>>> >>>> automatically makes these expressions numerically stable.
>>> >>>>
>>> >>>> You can find the project on github at:
>>> >>>> https://github.com/mikeizbicki/HerbiePlugin
>>> >>>> _______________________________________________
>>> >>>> Haskell-Cafe mailing list
>>> >>>> Haskell-Cafe at haskell.org
>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/f49eb4ad/attachment-0001.html>

From ch.howard at zoho.com  Tue Sep 22 23:19:58 2015
From: ch.howard at zoho.com (Christopher Howard)
Date: Tue, 22 Sep 2015 15:19:58 -0800
Subject: [Haskell-cafe] Simply and easy graphical toolkit?
Message-ID: <20150922151958.022241f4@nimrodel>

Hi. What would be the simplest and easiest Haskell graphical toolkit
to use? I remember a few years ago I tried Gloss and was really happy
with it, but I also wanted to be able to have a few buttons and text
fields on the screen for user input, without having to build them from
scratch.

-- 
http://justonemoremathproblem.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150922/09b22c77/attachment.sig>

From apfelmus at quantentunnel.de  Wed Sep 23 08:16:50 2015
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Wed, 23 Sep 2015 10:16:50 +0200
Subject: [Haskell-cafe] Simply and easy graphical toolkit?
In-Reply-To: <20150922151958.022241f4@nimrodel>
References: <20150922151958.022241f4@nimrodel>
Message-ID: <mttn5j$kr8$1@ger.gmane.org>

Dear Christopher,

I've built a small GUI library called Threepenny-GUI[1] for this 
purpose. Maybe that can help? It uses the web browser as a display, so 
it should be easy to install.

   [1]: https://wiki.haskell.org/Threepenny-gui


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


Christopher Howard wrote:
> Hi. What would be the simplest and easiest Haskell graphical toolkit
> to use? I remember a few years ago I tried Gloss and was really happy
> with it, but I also wanted to be able to have a few buttons and text
> fields on the screen for user input, without having to build them from
> scratch.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From silvio.frischi at gmail.com  Wed Sep 23 09:01:45 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Wed, 23 Sep 2015 11:01:45 +0200
Subject: [Haskell-cafe] Simply and easy graphical toolkit?
In-Reply-To: <20150922151958.022241f4@nimrodel>
References: <20150922151958.022241f4@nimrodel>
Message-ID: <56026A79.3020707@gmail.com>

GTK bindings is certainly a good conservative choice. It is flexible;
you can do anything you can do with gtk. It's also easy to use. You can
also use glade to help you desing ui's.

Cheers Silvio

From 6yearold at gmail.com  Wed Sep 23 10:33:28 2015
From: 6yearold at gmail.com (Gleb Popov)
Date: Wed, 23 Sep 2015 13:33:28 +0300
Subject: [Haskell-cafe] Simply and easy graphical toolkit?
In-Reply-To: <20150922151958.022241f4@nimrodel>
References: <20150922151958.022241f4@nimrodel>
Message-ID: <CALH631=+QhWDygWinyQp=iSzSDkBVzaK7CvFKy+c0cj5BtvqPw@mail.gmail.com>

On Wed, Sep 23, 2015 at 2:19 AM, Christopher Howard <ch.howard at zoho.com>
wrote:

> Hi. What would be the simplest and easiest Haskell graphical toolkit
> to use? I remember a few years ago I tried Gloss and was really happy
> with it, but I also wanted to be able to have a few buttons and text
> fields on the screen for user input, without having to build them from
> scratch.
>
> --
> http://justonemoremathproblem.com/
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
Elementary [1] toolkit is certainly simple, but binding for it are
currently WIP [2].

[1] : https://www.enlightenment.org/
[2] : https://bitbucket.org/arrowdodger/efl-haskell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150923/31c7c084/attachment.html>

From hvr at gnu.org  Wed Sep 23 11:17:22 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 23 Sep 2015 13:17:22 +0200
Subject: [Haskell-cafe] ANN: CfN for new Haskell Prime language committee
Message-ID: <87k2rh8jwd.fsf@gnu.org>

Dear Haskell Community,

In short, it's time to assemble a new Haskell Prime language
committee. Please refer to the CfN at

  https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

for more details.

Cheers,
  hvr

-- 
PGP fingerprint: 427C B69A AC9D 00F2 A43C  AF1C BA3C BA3F FE22 B574
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150923/45ee8cf4/attachment.sig>

From eir at cis.upenn.edu  Thu Sep 24 02:48:38 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 23 Sep 2015 22:48:38 -0400
Subject: [Haskell-cafe] Hac Phi: Haskell Exchange in Philadelphia, Nov 6-8
Message-ID: <0AF7A0FF-3237-41C3-8C19-11CE58E32862@cis.upenn.edu>

Hi caf?,

Hac Phi, a yearly weekend of Haskell in Philadelphia, will take place Nov. 6-8, hosted at the University of Pennsylvania. Hac Phi is a gathering of hackers and Haskell enthusiasts. Come bring a project you're working on or offer to help someone else on a project of theirs. Come give a talk if you've got something to share. Come to learn something new.

Though the event has the same structure as in previous years, it has been renamed from a Haskell Hackathon to a Haskell Exchange (not to be confused with The Haskell eXchange, a different event.) The organizers felt that the title "hackathon" has been given to events too unlike Hac Phi, events where participants code under pressure or over long times in competition. Those are fun affairs, indeed... but they're not like Hac Phi. So, we now say that Hac Phi is a yearly Haskell Exchange, where academics, professionals, and hobbyists can all meet, mingle, hack on each others' projects, and generally have a good time.

All the details are on the wiki page: https://wiki.haskell.org/Hac_Phi

I hope to see you there!
Richard

From mle+hs at mega-nerd.com  Thu Sep 24 05:10:25 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Thu, 24 Sep 2015 15:10:25 +1000
Subject: [Haskell-cafe] ANN: The Herbie GHC Plugin
In-Reply-To: <20150922160849.GA26757@fuzzbomb>
References: <CAKKZoUVtsphRwLBWg4W2H3Yu-gmu=uuwVAHwJ31uo0nEVsqwcg@mail.gmail.com>
 <CADnndOrdL2dY1Leq2uoVM6a2AcKmNvK2PANnJhj-ZwQRF0akyA@mail.gmail.com>
 <CAKKZoUWTJY=NGJM23kL5u8Eeif+tgzY-8CMB_bn1rBPPMGykUA@mail.gmail.com>
 <CADnndOpXcKWthOW33N209mx4fxVp1Qp4BNAYZV=WKyqTxi8MHg@mail.gmail.com>
 <1442937446.2471149.390590209.39465F94@webmail.messagingengine.com>
 <20150922160849.GA26757@fuzzbomb>
Message-ID: <20150924151025.98585ca47786e5eb7cbfd5d6@mega-nerd.com>

Bryan Richter wrote:

> I foresee -fwarn-numeric-instability!

Oh, yes, please!!!!

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From mwm at mired.org  Thu Sep 24 14:06:46 2015
From: mwm at mired.org (Mike Meyer)
Date: Thu, 24 Sep 2015 14:06:46 +0000
Subject: [Haskell-cafe] Simply and easy graphical toolkit?
In-Reply-To: <CALH631=+QhWDygWinyQp=iSzSDkBVzaK7CvFKy+c0cj5BtvqPw@mail.gmail.com>
References: <20150922151958.022241f4@nimrodel>
 <CALH631=+QhWDygWinyQp=iSzSDkBVzaK7CvFKy+c0cj5BtvqPw@mail.gmail.com>
Message-ID: <CAD=7U2C=yyn9LUto99QsJHeiUhRFYyvbUjnmuQ8jM85LgJwzUA@mail.gmail.com>

Not really an answer to your question, but more a hope that someone has
built something that would be. The nicest tool I've ever used for creating
GUIs that were mostly graphics with some clickable elements was JF
Bartlett's ezd. See
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.pdf for more info.

The diagrams package is easy to use, but more powerful than simple. With
the gtk backend you can get points from mouse clicks, The diagrams user
manual points out that the query feature of diagrams could use such clicks
to identify a set of elements that were clicked on, which could then be
used to find the code you want to run. So in theory, you could use diagrams
in a manner similar to the way ezd worked - but I couldn't seem to find an
example of this use.

On Wed, Sep 23, 2015 at 5:34 AM Gleb Popov <6yearold at gmail.com> wrote:

>
>
> On Wed, Sep 23, 2015 at 2:19 AM, Christopher Howard <ch.howard at zoho.com>
> wrote:
>
>> Hi. What would be the simplest and easiest Haskell graphical toolkit
>> to use? I remember a few years ago I tried Gloss and was really happy
>> with it, but I also wanted to be able to have a few buttons and text
>> fields on the screen for user input, without having to build them from
>> scratch.
>>
>> --
>> http://justonemoremathproblem.com/
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
> Elementary [1] toolkit is certainly simple, but binding for it are
> currently WIP [2].
>
> [1] : https://www.enlightenment.org/
> [2] : https://bitbucket.org/arrowdodger/efl-haskell
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150924/1895f7d1/attachment.html>

From nicola.gigante at gmail.com  Thu Sep 24 15:22:56 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 24 Sep 2015 17:22:56 +0200
Subject: [Haskell-cafe] STM implementation
Message-ID: <35A06315-9876-48B6-AD44-0460428705AF@gmail.com>

Hi all,

I?m considering the idea of hacking into the STM implementation, 
but the source in rts/STM.c seems rather dense.

Is there some documentation about the internals or some place
to start to understand what?s going on?

Thank you,
Nicola


From fryguybob at gmail.com  Thu Sep 24 15:28:01 2015
From: fryguybob at gmail.com (Ryan Yates)
Date: Thu, 24 Sep 2015 11:28:01 -0400
Subject: [Haskell-cafe] STM implementation
In-Reply-To: <35A06315-9876-48B6-AD44-0460428705AF@gmail.com>
References: <35A06315-9876-48B6-AD44-0460428705AF@gmail.com>
Message-ID: <CAO27hRrbjX9M0uUK=xmMrWK=-TAb6E5FG55tpL95s_qsrbJ6Lg@mail.gmail.com>

Hi Nicola,

There is the STM section of the GHC commentary:

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/STM

If anything is missing let me know!

Ryan


On Thu, Sep 24, 2015 at 11:22 AM, Nicola Gigante
<nicola.gigante at gmail.com> wrote:
> Hi all,
>
> I?m considering the idea of hacking into the STM implementation,
> but the source in rts/STM.c seems rather dense.
>
> Is there some documentation about the internals or some place
> to start to understand what?s going on?
>
> Thank you,
> Nicola
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From nicola.gigante at gmail.com  Thu Sep 24 15:43:37 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 24 Sep 2015 17:43:37 +0200
Subject: [Haskell-cafe] STM implementation
In-Reply-To: <CAO27hRrbjX9M0uUK=xmMrWK=-TAb6E5FG55tpL95s_qsrbJ6Lg@mail.gmail.com>
References: <35A06315-9876-48B6-AD44-0460428705AF@gmail.com>
 <CAO27hRrbjX9M0uUK=xmMrWK=-TAb6E5FG55tpL95s_qsrbJ6Lg@mail.gmail.com>
Message-ID: <D16A2AE2-9B0D-4D8B-9B3E-D6F78ABAC7FB@gmail.com>


> Il giorno 24/set/2015, alle ore 17:28, Ryan Yates <fryguybob at gmail.com> ha scritto:
> 
> Hi Nicola,
> 
> There is the STM section of the GHC commentary:
> 
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/STM
> 
> If anything is missing let me know!
> 

Thank you very much, It is what I was looking for :)

> Ryan

Greetings,
Nicola

From roma at ro-che.info  Fri Sep 25 06:42:43 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 25 Sep 2015 09:42:43 +0300
Subject: [Haskell-cafe] [Haskell] ANNOUNCE: polymap 0.1.0.1
In-Reply-To: <560446C3.1040404@gmail.com>
References: <560446C3.1040404@gmail.com>
Message-ID: <5604ECE3.8000703@ro-che.info>

(moving from haskell@ to haskell-cafe@)

Hi David,

As someone who is not familiar with the concept of polygonal maps, I
find this package severely underdocumented.

What is a polymap? Why would I want to use one? What is storage and how
should I choose it?

The example clears it up a bit, but it could also use more prose. And
perhaps there could be a more motivated example (showing how polymap
solves an actual problem).

On 09/24/2015 09:53 PM, David Farrell wrote:
> I'm excited to announce the first release of a package I've been working
> on over the last week called polymap, a library providing type-safe
> polygonal maps whose sides are defined by a kindlist of types zipped
> with a storage type for each side. I've tried to match the interface
> exposed by the containers package as closely as possible. For example:
> 
> import Data.Set (Set)
> import Data.PolyMap.Nat (first, second, third)
> import qualified Data.PolyMap as PM
> 
> mEmpty :: PM.PolyMap '[ '(String, Set), '(Int, Set) ]
> mEmpty = PM.empty
> 
> mOne :: PM.SimplePolyMap '[String, Int] Set
> mOne = PM.singleton ("one", length "one")
> 
> main = do
>     print mEmpty                              -- empty PolyMap
>     print mOne                                -- PolyMap with one Relation
>     print mTwo                                -- PolyMapwith two Relations
>     print (PM.member first "one" mTwo)        -- True
>     print (PM.notMember first "asdf" mTwo)    -- True
>     --print (PM.notMember second "asdf" mTwo) -- will not typecheck
>     --print (PM.notMember third "asdf" mTwo)  -- will not typecheck
>     print (PM.lookup first "two" mTwo)        -- second Relation of PolyMap
>   where mTwo = PM.insert ("two", length "two") mOne
> 
> This is a short usage example of most of the functions currently written
> for polymap. There's still a long way to go both in terms of exposed
> functions and in terms of efficiency and such, but I felt it prudent to
> make a public release of my work so far as I feel it's reached a stage
> where it could be beneficial to others. Note that GHC 7.10 (base >=4.8,
> GHC extensions) is required.
> 
> Git Repository:
> https://github.com/shockkolate/hs-polymap
> 
> Issue Tracker:
> https://github.com/shockkolate/hs-polymap
> 
> Hackage:
> https://hackage.haskell.org/package/polymap
> 
> The code is licensed under the Unlicense license--that is to say, the
> code is released into the public domain for the benefit of others.
> 
> I'd love to hear any feedback/suggestions/improvements/anything you want
> to say about polymap over the mailing list (which may be more suited to
> the haskell-cafe mailing list; I don't know) or in #haskell on Freenode
> (I'm usually in there as Shockk).
> 
> N.B. Version 0.1.0.0 of the package will not build due to the use of a
> function in containers that has been submitted as a pull request but
> does not exist yet/at all.
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150925/138405fc/attachment.sig>

From chneukirchen at gmail.com  Fri Sep 25 10:38:39 2015
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Fri, 25 Sep 2015 12:38:39 +0200
Subject: [Haskell-cafe] Munich Haskell Meeting, 2015-09-28 @ 19:30
Message-ID: <87a8salr68.fsf@gmail.com>

Dear all,

Next week, our monthly Munich Haskell Meeting will take place again on
Monday, September 28 at Cafe Puck at 19h30. For details see here:

http://chneukirchen.github.io/haskell-munich.de/dates
(http://www.haskell-munich.de/ is currently out of order, but will be
restored soon!)

If you plan to join, please add yourself to this dudle so we can
reserve enough seats!  It is OK to add yourself to the dudle
anonymously or pseudonymously.

https://dudle.inf.tu-dresden.de/haskell-munich-sep-2015/

Everybody is welcome!

cu,
-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

From takenobu.hs at gmail.com  Fri Sep 25 12:00:56 2015
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Fri, 25 Sep 2015 21:00:56 +0900
Subject: [Haskell-cafe] STM implementation
In-Reply-To: <D16A2AE2-9B0D-4D8B-9B3E-D6F78ABAC7FB@gmail.com>
References: <35A06315-9876-48B6-AD44-0460428705AF@gmail.com>
 <CAO27hRrbjX9M0uUK=xmMrWK=-TAb6E5FG55tpL95s_qsrbJ6Lg@mail.gmail.com>
 <D16A2AE2-9B0D-4D8B-9B3E-D6F78ABAC7FB@gmail.com>
Message-ID: <CAPB_Nvyw=fpPezQ0Ag4bofAzBPAJ3XtAUeAf3Vo7+Z3y2AF55w@mail.gmail.com>

Hi Nicola,

Is this useful for you?
There are few illustrations here:


http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=90

Enjoy!,
Takenobu


2015-09-25 0:43 GMT+09:00 Nicola Gigante <nicola.gigante at gmail.com>:

>
> > Il giorno 24/set/2015, alle ore 17:28, Ryan Yates <fryguybob at gmail.com>
> ha scritto:
> >
> > Hi Nicola,
> >
> > There is the STM section of the GHC commentary:
> >
> > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/STM
> >
> > If anything is missing let me know!
> >
>
> Thank you very much, It is what I was looking for :)
>
> > Ryan
>
> Greetings,
> Nicola
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150925/3214b229/attachment.html>

From manny at fpcomplete.com  Fri Sep 25 15:50:55 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Fri, 25 Sep 2015 08:50:55 -0700
Subject: [Haskell-cafe] ANN: stack-0.1.5.0
Message-ID: <CACGj5vJG_Ptym9r97ECVG9fgY3kxRGMEC+JmD=Yqj-DiTaH7xQ@mail.gmail.com>

New version released of stack, a build tool.

See README <https://github.com/commercialhaskell/stack#how-to-install> for
installation and upgrade instructions.

Note: the binary tarballs? contents have changed, and they now enclose
their contents in a directory, and include documentation. If you have a
script that should only extract the stack executable, use something like tar
xzf stack-0.1.5.0-x86_64-osx.tar.gz --strip-components=1
stack-0.1.5.0-x86_64-osx/stack.

MinGHC installers <https://github.com/fpco/minghc/releases> have also been
updated to include this version of stack (and will continue to be updated
for future releases).

Major changes:

   - On Windows, we now use a full MSYS2 installation in place of the
   previous PortableGit. This gives you access to the pacman package manager
   for more easily installing libraries.
   - Support for custom GHC binary distributions #530
   <https://github.com/commercialhaskell/stack/issues/530>
      - ghc-variant option in stack.yaml to specify the variant (also
      --ghc-variant command-line option)
      - setup-info in stack.yaml, to specify where to download custom binary
      distributions (also --ghc-bindist command-line option)
      - Note: On systems with libgmp4 (aka libgmp.so.3), such as CentOS 6,
      you
      may need to re-run stack setup due to the centos6 GHC bindist being
      treated like a variant
   - A new --pvp-bounds flag to the sdist and upload commands allows
   automatic adding of PVP upper and/or lower bounds to your dependencies

Other enhancements:

   - Adapt to upcoming Cabal installed package identifier format change #851
   <https://github.com/commercialhaskell/stack/issues/851>
   - stack setup takes a --stack-setup-yaml argument
   - --file-watch is more discerning about which files to rebuild for #912
   <https://github.com/commercialhaskell/stack/issues/912>
   - stack path now supports --global-pkg-db and --ghc-package-path
   - --reconfigure flag #914
   <https://github.com/commercialhaskell/stack/issues/914> #946
   <https://github.com/commercialhaskell/stack/issues/946>
   - Cached data is written with a checksum of its structure #889
   <https://github.com/commercialhaskell/stack/issues/889>
   - Fully removed --optimizations flag
   - Added --cabal-verbose flag
   - Added --file-watch-poll flag for polling instead of using filesystem
   events (useful for running tests in a Docker container while modifying code
   in the host environment. When code is injected into the container via a
   volume, the container won?t propagate filesystem events).
   - Give a preemptive error message when -prof is given as a GHC option
   #1015 <https://github.com/commercialhaskell/stack/issues/1015>
   - Locking is now optional, and will be turned on by setting the
   STACK_LOCK environment variable to true #950
   <https://github.com/commercialhaskell/stack/issues/950>
   - Create default stack.yaml with documentation comments and commented
   out options #226 <https://github.com/commercialhaskell/stack/issues/226>
   - Out of memory warning if Cabal exits with -9 #947
   <https://github.com/commercialhaskell/stack/issues/947>

Bug fixes:

   - Hacky workaround for optparse-applicative issue with stack exec --help
   #806 <https://github.com/commercialhaskell/stack/issues/806>
   - Build executables for local extra deps #920
   <https://github.com/commercialhaskell/stack/issues/920>
   - copyFile can?t handle directories #942
   <https://github.com/commercialhaskell/stack/pull/942>
   - Support for spaces in Haddock interface files fpco/minghc#85
   <https://github.com/fpco/minghc/issues/85>
   - Temporarily building against a ?shadowing? local package? #992
   <https://github.com/commercialhaskell/stack/issues/992>
   - Fix Setup.exe name for ?upgrade-cabal on Windows #1002
   <https://github.com/commercialhaskell/stack/issues/1002>
   - Unlisted dependencies no longer trigger extraneous second build #838
   <https://github.com/commercialhaskell/stack/issues/838>

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150925/a4b66362/attachment.html>

From dajfarrell at gmail.com  Fri Sep 25 18:34:33 2015
From: dajfarrell at gmail.com (David Farrell)
Date: Fri, 25 Sep 2015 19:34:33 +0100
Subject: [Haskell-cafe] [Haskell] ANNOUNCE: polymap 0.1.0.1
In-Reply-To: <5604ECE3.8000703@ro-che.info>
References: <560446C3.1040404@gmail.com> <5604ECE3.8000703@ro-che.info>
Message-ID: <560593B9.4020705@gmail.com>

Hello Roman,

Thanks for your feedback. These are good questions and I realize that 
not enough documentation on the concept or usage of polymaps is 
provided, so my next step will be to expand the Haddock documentation to 
include a detailed explanation of the concept and how to use the 
Relation data type and the Storage typeclass.

As far as what a polymap actually is, the example I've used to describe 
to concept to a couple of people is as follows. I'll briefly explain a 
couple of concepts first.

A unidirectional map--or just map for short--is a data structure holding 
a number of keys of some type and an identical number of values of some 
other type, forming a bijection between the keys and values. The data 
structure stores the keys and values in such a way so as to allow values 
to be looked up by their corresponding keys; in other words, each key 
maps to the corresponding value. To illustrate this mapping:

A==>B

A bidirectional map is similar to a map with the difference that each 
value also maps back to its corresponding key, allowing two-way 
(bidirectional) mapping between the keys and values. In the case of a 
bimap, it may be more useful to refer to both the keys and values as a 
set of keys on one of the sides of the bimap. To illustrate this mapping:

A<=>B

Or to illustrate more consistently for the illustration following this one:

A---B

A 3-sided map builds on these concepts, applying them to three sides as 
opposed to two (left and right), creating a relational mapping between 
three different sets of keys where each side maps to every other side. 
To illustrate this mapping:

A---B
|  /
| /
|/
C

Similarly, a 4-sided map is illustrated as:

A---B
|\ /|
| X |
|/ \|
C---D

A polymap essentially generalizes these previous examples as an n-sided 
map, allowing values to looked up by any of their of corresponding keys 
on one of the sides of the polymap.

I hope this clears things up somewhat with respect to what a polymap is. 
I'll be adding Haddock explaining all of this as well as Storage and 
Relation and the definitions in Data.PolyMap.Nat as soon as I get the 
chance.

Apologies for my awful ASCII illustrations.

On 25/09/2015 07:42, Roman Cheplyaka wrote:
> (moving from haskell@ to haskell-cafe@)
>
> Hi David,
>
> As someone who is not familiar with the concept of polygonal maps, I
> find this package severely underdocumented.
>
> What is a polymap? Why would I want to use one? What is storage and how
> should I choose it?
>
> The example clears it up a bit, but it could also use more prose. And
> perhaps there could be a more motivated example (showing how polymap
> solves an actual problem).
>
> On 09/24/2015 09:53 PM, David Farrell wrote:
>> I'm excited to announce the first release of a package I've been working
>> on over the last week called polymap, a library providing type-safe
>> polygonal maps whose sides are defined by a kindlist of types zipped
>> with a storage type for each side. I've tried to match the interface
>> exposed by the containers package as closely as possible. For example:
>>
>> import Data.Set (Set)
>> import Data.PolyMap.Nat (first, second, third)
>> import qualified Data.PolyMap as PM
>>
>> mEmpty :: PM.PolyMap '[ '(String, Set), '(Int, Set) ]
>> mEmpty = PM.empty
>>
>> mOne :: PM.SimplePolyMap '[String, Int] Set
>> mOne = PM.singleton ("one", length "one")
>>
>> main = do
>>      print mEmpty                              -- empty PolyMap
>>      print mOne                                -- PolyMap with one Relation
>>      print mTwo                                -- PolyMapwith two Relations
>>      print (PM.member first "one" mTwo)        -- True
>>      print (PM.notMember first "asdf" mTwo)    -- True
>>      --print (PM.notMember second "asdf" mTwo) -- will not typecheck
>>      --print (PM.notMember third "asdf" mTwo)  -- will not typecheck
>>      print (PM.lookup first "two" mTwo)        -- second Relation of PolyMap
>>    where mTwo = PM.insert ("two", length "two") mOne
>>
>> This is a short usage example of most of the functions currently written
>> for polymap. There's still a long way to go both in terms of exposed
>> functions and in terms of efficiency and such, but I felt it prudent to
>> make a public release of my work so far as I feel it's reached a stage
>> where it could be beneficial to others. Note that GHC 7.10 (base >=4.8,
>> GHC extensions) is required.
>>
>> Git Repository:
>> https://github.com/shockkolate/hs-polymap
>>
>> Issue Tracker:
>> https://github.com/shockkolate/hs-polymap
>>
>> Hackage:
>> https://hackage.haskell.org/package/polymap
>>
>> The code is licensed under the Unlicense license--that is to say, the
>> code is released into the public domain for the benefit of others.
>>
>> I'd love to hear any feedback/suggestions/improvements/anything you want
>> to say about polymap over the mailing list (which may be more suited to
>> the haskell-cafe mailing list; I don't know) or in #haskell on Freenode
>> (I'm usually in there as Shockk).
>>
>> N.B. Version 0.1.0.0 of the package will not build due to the use of a
>> function in containers that has been submitted as a pull request but
>> does not exist yet/at all.
>> _______________________________________________
>> Haskell mailing list
>> Haskell at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>>
>


From fr33domlover at riseup.net  Sat Sep 26 07:59:12 2015
From: fr33domlover at riseup.net (fr33domlover)
Date: Sat, 26 Sep 2015 10:59:12 +0300
Subject: [Haskell-cafe] Parsing Atom feed link
Message-ID: <mailman.0.1443254047.13544.haskell-cafe@haskell.org>

Hello,

I'm using the package 'feed' to parse news feeds and I noticed it fails to
parse the item links of many feeds! I investigated and apparently here is why.
Many Atom feeds in practice seem to publish their item links like this:

<link href="http://....."/>

But in the 'feed' package, a link is taken to be an item link only if its
relation is alternate, i.e. add an attribute rel="alternate". So for these
feeds it returns 'Nothing' for 'getItemLink'.

A quick workaround is to go over the links manually of course, which solves the
issue locally, but I think it should be solved more generally.



Is the problem in 'feed' which recognizes links incorrectly, or do those Atom
feeds simply use the wrong way to publish item links? Are they required to use
"alternate"?

I looked at the examples at https://tools.ietf.org/html/rfc4287 and I just
checked Octopress (Ruby) and Ikiwiki (Perl) generated feeds. The RFC's examples
have item links without "alernate" (as the only item link provided) and both
generators I mentioned create feed item links without "alternate".


Should 'feed' be fixed to recognize them?

From the RFC:

atom:link elements MAY have a "rel" attribute that indicates the
link relation type. If the "rel" attribute is not present, the
link element MUST be interpreted as if the link relation type
is "alternate".


--fr33

From fa-ml at ariis.it  Sat Sep 26 08:15:24 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sat, 26 Sep 2015 10:15:24 +0200
Subject: [Haskell-cafe] Parsing Atom feed link
In-Reply-To: <20150926075408.CA6FEBCAD4@haskell.org>
References: <20150926075408.CA6FEBCAD4@haskell.org>
Message-ID: <20150926081524.GA13662@casa.casa>

On Sat, Sep 26, 2015 at 10:59:12AM +0300, fr33domlover wrote:
> Hello,
> 
> I'm using the package 'feed' to parse news feeds and I noticed it fails to
> parse the item links of many feeds! I investigated and apparently here is why.
> Many Atom feeds in practice seem to publish their item links like this:
> 
> <link href="http://....."/>

Checking the code [1] it looks like it is indeed the case

    linkRel = Right `fmap` pAttr "rel" e

[1] http://hackage.haskell.org/package/feed-0.3.10.1/docs/src/Text-Atom-Feed-Import.html#pLink

> I looked at the examples at https://tools.ietf.org/html/rfc4287 and I just
> checked Octopress (Ruby) and Ikiwiki (Perl) generated feeds. The RFC's examples
> have item links without "alernate" (as the only item link provided) and both
> generators I mentioned create feed item links without "alternate".
> 
> 
> Should 'feed' be fixed to recognize them?

Since you have done the homework and this is rfc compliant, have you
tried sending an email to the maintainer [1]?
It seems an uncontroversial change and they are active (last version
released in 2015), I bet they are be willing to fix this.

[1] http://hackage.haskell.org/package/feed


From m at pavis.biodec.com  Sat Sep 26 09:33:39 2015
From: m at pavis.biodec.com (m)
Date: Sat, 26 Sep 2015 11:33:39 +0200
Subject: [Haskell-cafe] Bologna Haskell Meeting, 2015-10-17 @ 9:30
Message-ID: <20150926093339.GH16555@pavis.biodec.com>

Dear all,
     a Bologna Haskell Meeting will take place on Saturday, October 17 at
9:30. For details see here:

https://www.eventbrite.it/e/biglietti-incontro-autunnale-haskell-ita-a-bologna-17894558105

The page is in Italian and English: the main event is in Italian but
many people speak English and we will try to include as many
participants as possible. If you would like to give a talk, drop a note
to Haskell_ITA at googlegroups.com (there is probably still a free slot at
the beginning or at the end of the evening).

In the same building there will also be an Elixir meeting:

https://www.eventbrite.it/e/biglietti-bologna-elixir-erlang-meetup-18440536140

(but we have a bigger and better meeting room ...) and participants to a
meeting can also lurk the other event.

Everybody is welcome! And if you are interested in participating to the
event, please buy a ticket on Eventbrite (it is free) just for the
meeting that you plan to attend to.

Thanks, and see you in Bologna, if you happen to be around.

P.S.: if anybody is travelling and needs further information about
hotels, travel, etcetera, feel free to contact me directly, I'll be glad
to help. 

-- 
  .*.                            finelli
  /V\
(/ \) --------------------------------------------------------------
(   )       Linux: Friends dont let friends use Piccolosoffice
^^-^^ --------------------------------------------------------------

A mother takes twenty years to make a man of her boy, and another woman
makes a fool of him in twenty minutes.
		-- Frost

From nicola.gigante at gmail.com  Sat Sep 26 12:25:27 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sat, 26 Sep 2015 14:25:27 +0200
Subject: [Haskell-cafe] STM implementation
In-Reply-To: <CAPB_Nvyw=fpPezQ0Ag4bofAzBPAJ3XtAUeAf3Vo7+Z3y2AF55w@mail.gmail.com>
References: <35A06315-9876-48B6-AD44-0460428705AF@gmail.com>
 <CAO27hRrbjX9M0uUK=xmMrWK=-TAb6E5FG55tpL95s_qsrbJ6Lg@mail.gmail.com>
 <D16A2AE2-9B0D-4D8B-9B3E-D6F78ABAC7FB@gmail.com>
 <CAPB_Nvyw=fpPezQ0Ag4bofAzBPAJ3XtAUeAf3Vo7+Z3y2AF55w@mail.gmail.com>
Message-ID: <AF2D80E0-9A1B-4D8A-8BE4-F948AF63C697@gmail.com>


> Il giorno 25/set/2015, alle ore 14:00, Takenobu Tani <takenobu.hs at gmail.com> ha scritto:
> 
> Hi Nicola,
> 
> Is this useful for you?
> There are few illustrations here:
> 
>     http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=90 <http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=90>
> 

Yes, that?s also very useful! 

> Enjoy!,
> Takenobu

Thank you!

Nicola

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150926/d24e14c6/attachment.html>

From capn.freako at gmail.com  Sun Sep 27 14:33:06 2015
From: capn.freako at gmail.com (David Banas)
Date: Sun, 27 Sep 2015 07:33:06 -0700
Subject: [Haskell-cafe] Solutions to Typeclassopedia Ex. 3.3.1?
Message-ID: <5731A837-156D-4172-AF5A-5B87B2A6D5D5@gmail.com>

Would anyone care to share their solution to exercise 3.3.1 in Typeclassopedia?

Thanks,
-db

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150927/bcf26952/attachment.html>

From sumit.sahrawat.apm13 at iitbhu.ac.in  Sun Sep 27 14:52:55 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Sun, 27 Sep 2015 20:22:55 +0530
Subject: [Haskell-cafe] Solutions to Typeclassopedia Ex. 3.3.1?
In-Reply-To: <5731A837-156D-4172-AF5A-5B87B2A6D5D5@gmail.com>
References: <5731A837-156D-4172-AF5A-5B87B2A6D5D5@gmail.com>
Message-ID: <CAJbEW8Ou6guvZZ3uaimhGHUh4HtpZK6R1H50U39Kykqqu3uM9Q@mail.gmail.com>

The holy source :)

https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#line-614

https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Either.html#line-128

On 27 September 2015 at 20:03, David Banas <capn.freako at gmail.com> wrote:

> Would anyone care to share their solution to exercise 3.3.1 in
> *Typeclassopedia*?
>
> Thanks,
> -db
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150927/7ad69851/attachment.html>

From fa-ml at ariis.it  Sun Sep 27 15:11:46 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 27 Sep 2015 17:11:46 +0200
Subject: [Haskell-cafe] Solutions to Typeclassopedia Ex. 3.3.1?
In-Reply-To: <CAJbEW8Ou6guvZZ3uaimhGHUh4HtpZK6R1H50U39Kykqqu3uM9Q@mail.gmail.com>
References: <5731A837-156D-4172-AF5A-5B87B2A6D5D5@gmail.com>
 <CAJbEW8Ou6guvZZ3uaimhGHUh4HtpZK6R1H50U39Kykqqu3uM9Q@mail.gmail.com>
Message-ID: <20150927151146.GA7854@casa.casa>

On Sun, Sep 27, 2015 at 08:22:55PM +0530, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote:
> The holy source :)
> 
> https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#line-614
> 
> https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Either.html#line-128
> 

instance Functor (Either a) where
    fmap _ (Left x) = Left x
    fmap f (Right y) = Right (f y)

`fmap id = id` and `fmap (f . g)  = fmap f . fmap g` seem to hold here, no?

From aovieth at gmail.com  Sun Sep 27 18:10:50 2015
From: aovieth at gmail.com (Alexander Vieth)
Date: Sun, 27 Sep 2015 14:10:50 -0400
Subject: [Haskell-cafe] Constrain Symbol to contain only alphabetic
	characters
Message-ID: <CAE2LzdX2fy+kMZQD6Xb+Ei60pLd=pNJOWnzXbULDzqZrLOPeNg@mail.gmail.com>

Hi Caf?,

Is it possible to do this? I looked through the source for GHC.TypeLits on
hackage but found no leads.

Thanks for any help,

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150927/5a60bb4b/attachment.html>

From rf at rufflewind.com  Sun Sep 27 18:56:56 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Sun, 27 Sep 2015 14:56:56 -0400
Subject: [Haskell-cafe] Solutions to Typeclassopedia Ex. 3.3.1?
In-Reply-To: <5731A837-156D-4172-AF5A-5B87B2A6D5D5@gmail.com>
References: <5731A837-156D-4172-AF5A-5B87B2A6D5D5@gmail.com>
Message-ID: <CADb8sTNsDLDb6m27aLhqDPJUgB8RSyQQ7+XAO4JpR1mjg__BDQ@mail.gmail.com>

> Would anyone care to share their solution to exercise 3.3.1 in
> Typeclassopedia?

http://stackoverflow.com/a/13539433

From eir at cis.upenn.edu  Sun Sep 27 19:03:17 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 27 Sep 2015 15:03:17 -0400
Subject: [Haskell-cafe] Constrain Symbol to contain only alphabetic
	characters
In-Reply-To: <CAE2LzdX2fy+kMZQD6Xb+Ei60pLd=pNJOWnzXbULDzqZrLOPeNg@mail.gmail.com>
References: <CAE2LzdX2fy+kMZQD6Xb+Ei60pLd=pNJOWnzXbULDzqZrLOPeNg@mail.gmail.com>
Message-ID: <4793B9EA-C7B7-484D-87EC-EA9BC893BC21@cis.upenn.edu>

I don't believe so. I think there's lots of room for improvement over the current capabilities for Symbol -- it was originally designed, I think, to be useful for record labels, so it didn't need any ability to decompose.

In the meantime, you could probably get what you need by using a list of one-character symbols and treating the list as a string. Use a quasiquoter to make the surface syntax palatable. You may also want lots of type-level manipulation functions as provided by the singletons library, which includes almost all of Data.List at the type level in its Data.Promotion.Prelude.List module.

Richard

On Sep 27, 2015, at 2:10 PM, Alexander Vieth <aovieth at gmail.com> wrote:

> Hi Caf?,
> 
> Is it possible to do this? I looked through the source for GHC.TypeLits on hackage but found no leads.
> 
> Thanks for any help,
> 
> Alex
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From sumit.sahrawat.apm13 at iitbhu.ac.in  Sun Sep 27 20:50:40 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Mon, 28 Sep 2015 02:20:40 +0530
Subject: [Haskell-cafe] Solutions to Typeclassopedia Ex. 3.3.1?
In-Reply-To: <CADb8sTNsDLDb6m27aLhqDPJUgB8RSyQQ7+XAO4JpR1mjg__BDQ@mail.gmail.com>
References: <5731A837-156D-4172-AF5A-5B87B2A6D5D5@gmail.com>
 <CADb8sTNsDLDb6m27aLhqDPJUgB8RSyQQ7+XAO4JpR1mjg__BDQ@mail.gmail.com>
Message-ID: <CAJbEW8M+381prUOqsYDjLLwYLV-+irji3AZCjaz=U5oLgg9azQ@mail.gmail.com>

Sorry, it seems like I got excited and posted solutions to 3.2.1 instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150928/136de738/attachment.html>

From fr33domlover at riseup.net  Sun Sep 27 21:17:34 2015
From: fr33domlover at riseup.net (fr33domlover)
Date: Mon, 28 Sep 2015 00:17:34 +0300
Subject: [Haskell-cafe] Parsing Atom feed link
In-Reply-To: <20150926081524.GA13662@casa.casa>
References: <20150926075408.CA6FEBCAD4@haskell.org>
 <20150926081524.GA13662@casa.casa>
Message-ID: <mailman.1.1443388342.13544.haskell-cafe@haskell.org>

On Sat, 26 Sep 2015 10:15:24 +0200
Francesco Ariis <fa-ml at ariis.it> wrote:

> 
> Since you have done the homework and this is rfc compliant, have you
> tried sending an email to the maintainer [1]?
> It seems an uncontroversial change and they are active (last version
> released in 2015), I bet they are be willing to fix this.
> 
> [1] http://hackage.haskell.org/package/feed

I sent the message to the maintainer too. I'm tempted to add a quick
temporary fix to my code, but hopefully this issue will get fixed soon
anyway.

From strikingwolf2012 at gmail.com  Mon Sep 28 01:11:00 2015
From: strikingwolf2012 at gmail.com (Strikingwolf2012 .)
Date: Sun, 27 Sep 2015 20:11:00 -0500
Subject: [Haskell-cafe] Fmap and Map for lists
Message-ID: <CAEVsWh501n0Jz1bKkBR5RQrjBiUvzbeFX3AhBf1we_BjFzFpOA@mail.gmail.com>

Does anyone have any idea why fmap (Functor map) and the list map are
separate functions? I think it would make plenty sense for the Functor map
to just be named map and have lists respond to that
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150927/de1d866b/attachment.html>

From fa-ml at ariis.it  Mon Sep 28 01:12:23 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Mon, 28 Sep 2015 03:12:23 +0200
Subject: [Haskell-cafe] Fmap and Map for lists
In-Reply-To: <CAEVsWh501n0Jz1bKkBR5RQrjBiUvzbeFX3AhBf1we_BjFzFpOA@mail.gmail.com>
References: <CAEVsWh501n0Jz1bKkBR5RQrjBiUvzbeFX3AhBf1we_BjFzFpOA@mail.gmail.com>
Message-ID: <20150928011223.GA15144@casa.casa>

On Sun, Sep 27, 2015 at 08:11:00PM -0500, Strikingwolf2012 . wrote:
> Does anyone have any idea why fmap (Functor map) and the list map are
> separate functions? I think it would make plenty sense for the Functor map
> to just be named map and have lists respond to that

http://stackoverflow.com/questions/6824255/whats-the-point-of-map-in-haskell-when-there-is-fmap/6824333

tl;dr: Historical reasons, have more of this
here https://wiki.haskell.org/Nitpicks

From jeffbrown.the at gmail.com  Mon Sep 28 07:28:10 2015
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Mon, 28 Sep 2015 00:28:10 -0700
Subject: [Haskell-cafe] Parsing, infixes and on-the-fly precedence
Message-ID: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>

I imagine a parser that operates on (String,[String]) pairs, for which the
second element allows the user to define precedence on the fly.

For instance, it would read the pair
  (x,y) = ("a , b : c", [":" , ","])
as
  "(a , (b : c))"
because y informs the parser that in x the colon binds first, then the
comma.

I know it is possible, because Haskell does it already! In Haskell we can
define novel infix operators on the fly, including their precedence
relative to each other.

I don't know how, though, so that's my question.

-- 
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150928/af69ff6d/attachment.html>

From lambda.fairy at gmail.com  Mon Sep 28 07:58:50 2015
From: lambda.fairy at gmail.com (Chris Wong)
Date: Mon, 28 Sep 2015 20:58:50 +1300
Subject: [Haskell-cafe] Parsing, infixes and on-the-fly precedence
In-Reply-To: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>
References: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>
Message-ID: <CANQO64JSpVQCE+QbyyZs3Gt2Os-JAyFru1cC_n-5i3txTgeq5Q@mail.gmail.com>

Hi Jeffrey,

On Mon, Sep 28, 2015 at 8:28 PM, Jeffrey Brown <jeffbrown.the at gmail.com> wrote:
> I imagine a parser that operates on (String,[String]) pairs, for which the
> second element allows the user to define precedence on the fly.
>
> For instance, it would read the pair
>   (x,y) = ("a , b : c", [":" , ","])
> as
>   "(a , (b : c))"
> because y informs the parser that in x the colon binds first, then the
> comma.
>
> I know it is possible, because Haskell does it already! In Haskell we can
> define novel infix operators on the fly, including their precedence relative
> to each other.
>
> I don't know how, though, so that's my question.

You might like to look at Text.Parsec.Token[1], which does exactly
what you describe.

[1] https://hackage.haskell.org/package/parsec-3.1.9/docs/Text-Parsec-Expr.html

> --
> Jeffrey Benjamin Brown
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Wong (https://lambda.xyz)

"I fear that Haskell is doomed to succeed."
    -- Tony Hoare

From lambda.fairy at gmail.com  Mon Sep 28 08:00:12 2015
From: lambda.fairy at gmail.com (Chris Wong)
Date: Mon, 28 Sep 2015 21:00:12 +1300
Subject: [Haskell-cafe] Parsing, infixes and on-the-fly precedence
In-Reply-To: <CANQO64JSpVQCE+QbyyZs3Gt2Os-JAyFru1cC_n-5i3txTgeq5Q@mail.gmail.com>
References: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>
 <CANQO64JSpVQCE+QbyyZs3Gt2Os-JAyFru1cC_n-5i3txTgeq5Q@mail.gmail.com>
Message-ID: <CANQO64+VPQ-4triPbHuU=a84WOTba8iUW8mrtKtTYJWHO=N77A@mail.gmail.com>

On Mon, Sep 28, 2015 at 8:58 PM, Chris Wong <lambda.fairy at gmail.com> wrote:
> Hi Jeffrey,
>
> [snip]
>
> You might like to look at Text.Parsec.Token[1], which does exactly
> what you describe.
>
> [1] https://hackage.haskell.org/package/parsec-3.1.9/docs/Text-Parsec-Expr.html

Whoops, I meant "Text.Parsec.Expr". But you can probably figure that
out from context :)

-- 
Chris Wong (https://lambda.xyz)

"I fear that Haskell is doomed to succeed."
    -- Tony Hoare

From adam at bergmark.nl  Mon Sep 28 08:31:00 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Mon, 28 Sep 2015 10:31:00 +0200
Subject: [Haskell-cafe] Parsing Atom feed link
In-Reply-To: <20150927211224.251C1BCEC0@haskell.org>
References: <20150926075408.CA6FEBCAD4@haskell.org>
 <20150926081524.GA13662@casa.casa>
 <20150927211224.251C1BCEC0@haskell.org>
Message-ID: <CACnqJZbLeqVk1BrKvTxbZUxXockgz8fyNU1f0WH1BFAwnLpJnA@mail.gmail.com>

Hi,

This sounds like a good change to me!

Are you willing to provide a patch (and maybe a testcase??) for this?

- Adam

On Sun, Sep 27, 2015 at 11:17 PM, fr33domlover <fr33domlover at riseup.net>
wrote:

> On Sat, 26 Sep 2015 10:15:24 +0200
> Francesco Ariis <fa-ml at ariis.it> wrote:
>
> >
> > Since you have done the homework and this is rfc compliant, have you
> > tried sending an email to the maintainer [1]?
> > It seems an uncontroversial change and they are active (last version
> > released in 2015), I bet they are be willing to fix this.
> >
> > [1] http://hackage.haskell.org/package/feed
>
> I sent the message to the maintainer too. I'm tempted to add a quick
> temporary fix to my code, but hopefully this issue will get fixed soon
> anyway.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150928/a99dbd6d/attachment.html>

From monnier at iro.umontreal.ca  Mon Sep 28 13:57:38 2015
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Mon, 28 Sep 2015 09:57:38 -0400
Subject: [Haskell-cafe] Parsing, infixes and on-the-fly precedence
References: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>
Message-ID: <jwv7fnawt27.fsf-monnier+gmane.comp.lang.haskell.cafe@gnu.org>

> I know it is possible, because Haskell does it already! In Haskell we can
> define novel infix operators on the fly, including their precedence
> relative to each other.
> I don't know how, though, so that's my question.

You might like to look at
https://en.wikipedia.org/wiki/Operator-precedence_grammar


        Stefan


From matteo.ferrando2 at gmail.com  Mon Sep 28 21:36:43 2015
From: matteo.ferrando2 at gmail.com (Matteo Ferrando)
Date: Mon, 28 Sep 2015 17:06:43 -0430
Subject: [Haskell-cafe] Using Parsec with a recursive data as the stream
Message-ID: <CAMmkxPbAES1b2y5adD-_P4h6XgD-7jXgm1nyi4wqeZ3cdc+9vw@mail.gmail.com>

Hello, I've posted this question in StackOverflow[1], but I thought
this would be a good place to ask too:

I'm writing an interpreter for functional programming language with
with *mixfix operators*, just like Agda[2]. I used their paper[3] as
reference.

    if_then_else_ : Bool -> a -> a -> a
    if True then x else _  = x
    if False then _ else x = x

    _/\_ : Bool -> Bool -> Bool
    True /\ True = True
    _ /\ _ = False

So that means I had to run a parser (I used Alex/Happy), to get an AST,
with this specific part (smaller than actual `Expr`):

    data Expr
      = Id String
      | Apply [Expr]
      | Forall Type Expr

    data Type = TypeBind String Expr


And with this `Expr`, I have to run a second parser
(which I intend to use Parsec) to do the following kind of processing:

    ? let example = Apply [Id "if", Id "a", Id "/\\", Id "b", Id "then", Id
"c", Id "else", Id "d"]
    ? parseMixfix example
    Right (Apply [Id "if_then_else_",Apply [Id "_/\\_",Id "a",Id "b"],Id
"c",Id "d"])

I started with a Parser that received a `Stream` of `[Expr]`, but this only
accepts the lists in a `Apply`, and doesn't go deep in the *tree*, just
parses
on the top level.

So I'm considering the option of instead of using `[Expr]` as the `Stream`,
to use `Expr`, having to do the `Stream` instance for it; this is where I'm
at:

    data Tok a = This a | Over (Tok a) deriving (Show)

    instance (Monad m) => Stream Expr m (Tok Expr) where
            uncons ex = check ex
                where
                    check :: Monad m => Expr -> m (Maybe (Tok Expr, Expr))
                    check ex = case ex of
                            Id s         -> return $ Just (This (Id s),
Apply [])
                            Apply (x:xs) -> do
                                    mst <- check x
                                    return $ fmap (\(a, b) -> (Over a, b))
mst

Which is using `data Tok` as kind of a Zipper breadcrumb
(or at least I see it that way), to indicate how deep in the tree it comes
from.

I know this is not the correct code, but is for you folks to get the idea.
I'm wondering if I'm on the right track or if there's a better solution for
this
problem. I'm also missing the `Forall` case here; that's because I was
making
tests with an `Id | Apply` only tree before.

[1]: http://stackoverflow.com/posts/32831287
[2]: http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Mixfix
[3]:
http://www.cse.chalmers.se/~nad/publications/danielsson-norell-mixfix.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150928/da2cfa28/attachment.html>

From ky3 at atamo.com  Tue Sep 29 03:07:44 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 29 Sep 2015 10:07:44 +0700
Subject: [Haskell-cafe] Parsing, infixes and on-the-fly precedence
In-Reply-To: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>
References: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>
Message-ID: <CAPY+ZdRDU_+24AEguqSWJMkHezvjt5GnG-AKioKgpaunbEHAxw@mail.gmail.com>

On Mon, Sep 28, 2015 at 2:28 PM, Jeffrey Brown <jeffbrown.the at gmail.com>
wrote:

> I imagine a parser that operates on (String,[String]) pairs, for which the
> second element allows the user to define precedence on the fly.


Let's use the Parser newtype

newtype Parser a = Parser { parse :: String -> [(a,String)] }

from

http://dev.stephendiehl.com/fun/002_parsers.html

as a basis for discussion.

Now you want to "operate on (String,[String]) pairs", so the Parser newtype
must now look like this:

type MyInput = (String,[String])

newtype MyParser a = MyParser { parse :: MyInput -> [(a,MyInput)] }

Is this what you have in mind?

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150929/63554ccf/attachment.html>

From capn.freako at gmail.com  Tue Sep 29 14:48:05 2015
From: capn.freako at gmail.com (David Banas)
Date: Tue, 29 Sep 2015 07:48:05 -0700
Subject: [Haskell-cafe] Question, re: Typeclassopedia Ex. 4.2.1
Message-ID: <84140687-CD45-4822-8844-61F8F440D0B6@gmail.com>

Hi all,

In trying to solve exercise 4.2.1 in Typeclassopedia, I?ve come up with the following:

To prove:
pure f <*> x = pure (flip ($)) <*> x <*> pure f
Proof:
pure (flip ($)) <*> x <*> pure f     = (interchange)
pure (flip ($)) <*> pure ($ f) <*> x = (homomorphism)
pure (flip ($) ($ f)) <*> x          = (definition of flip)
pure ($ ($ f)) <*> x                 = (interchange)
x <*> pure ($ f)                     = (interchange) (Is this step valid?)
pure f <*> x
Is the last step in my proof valid?

Thanks,
-db

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150929/a7a90456/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Sep 29 15:40:38 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 29 Sep 2015 16:40:38 +0100
Subject: [Haskell-cafe] Question, re: Typeclassopedia Ex. 4.2.1
In-Reply-To: <84140687-CD45-4822-8844-61F8F440D0B6@gmail.com>
References: <84140687-CD45-4822-8844-61F8F440D0B6@gmail.com>
Message-ID: <20150929154037.GS14111@weber>

On Tue, Sep 29, 2015 at 07:48:05AM -0700, David Banas wrote:
> pure (flip ($)) <*> x <*> pure f     = (interchange)
> pure (flip ($)) <*> pure ($ f) <*> x = (homomorphism)

For one thing, this step doesn't look right.   <*> does not associate that
way.

It's probably worth at least putting each expression into ghci to check they
have the same time

    Prelude> import Control.Applicative
    Prelude Control.Applicative> let l = \x f -> pure (flip ($)) <*> x <*> pure f
    Prelude Control.Applicative> :t l
    l :: Applicative f => f a -> (a -> b) -> f b
    Prelude Control.Applicative> let l2 = \x f -> pure (flip ($)) <*> pure ($ f) <*> x
    Prelude Control.Applicative> :t l2
    l2 :: Applicative f => f (((a -> b1) -> b1) -> b) -> a -> f b

I imagine you're probably going to want to go via ($ x) rather than ($ f),
and possibly use that 'pure f <*> x = fmap f x = ($ x) <*> pure f'.

Tom

From fr33domlover at riseup.net  Tue Sep 29 16:12:41 2015
From: fr33domlover at riseup.net (fr33domlover at riseup.net)
Date: Tue, 29 Sep 2015 19:12:41 +0300
Subject: [Haskell-cafe] [PATCH] Interpret missing link relation in Atom as
	"alternate"
In-Reply-To: <CACnqJZbLeqVk1BrKvTxbZUxXockgz8fyNU1f0WH1BFAwnLpJnA@mail.gmail.com>
References: <CACnqJZbLeqVk1BrKvTxbZUxXockgz8fyNU1f0WH1BFAwnLpJnA@mail.gmail.com>
Message-ID: <1443543161-21716-1-git-send-email-fr33domlover@riseup.net>

From: fr33domlover <fr33domlover at riseup.net>

The Atom RFC says that when a link element doesn't
specify the "rel" attribute, i.e. link relation, it
should be interpreted as an "alternate" relation.
This commit makes the feed and item query functions
treat a missing relation as "alternate".
---
 feed.cabal               |    5 +-
 src/Text/Feed/Query.hs   |   11 +-
 tests/Main.hs            |    9 +-
 tests/Text/Atom/Tests.hs |   39 +
 tests/files/atom.xml     | 6733 ++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 6789 insertions(+), 8 deletions(-)
 create mode 100644 tests/Text/Atom/Tests.hs
 create mode 100644 tests/files/atom.xml

diff --git a/feed.cabal b/feed.cabal
index b22dfed..8c04444 100644
--- a/feed.cabal
+++ b/feed.cabal
@@ -17,7 +17,9 @@ homepage:            https://github.com/bergmark/feed
 bug-reports:         https://github.com/bergmark/feed/issues
 cabal-version:       >= 1.8
 build-type:          Simple
-data-files:          tests/files/rss20.xml
+data-files:
+  tests/files/rss20.xml
+  tests/files/atom.xml
 extra-source-files:
   README.md
   CHANGELOG.md
@@ -68,6 +70,7 @@ test-suite tests
   main-is:           Main.hs
   type:              exitcode-stdio-1.0
   other-modules:
+    Text.Atom.Tests
     Text.RSS.Equals
     Text.RSS.Export.Tests
     Text.RSS.Import.Tests
diff --git a/src/Text/Feed/Query.hs b/src/Text/Feed/Query.hs
index 970d17b..0a599c7 100644
--- a/src/Text/Feed/Query.hs
+++ b/src/Text/Feed/Query.hs
@@ -129,7 +129,9 @@ getFeedHTML ft =
         Just e1 -> fmap XML.strContent $ findElement (unqual "link") e1
         Nothing -> Nothing
  where
-  isSelf lr = toStr (Atom.linkRel lr) == "alternate" && isHTMLType (linkType lr)
+  isSelf lr =
+    let rel = Atom.linkRel lr
+    in  (isNothing rel || toStr rel == "alternate") && isHTMLType (linkType lr)
 
   isHTMLType (Just str) = "lmth" `isPrefixOf` (reverse str)
   isHTMLType _ = True -- if none given, assume html.
@@ -243,13 +245,16 @@ getItemTitle it =
 getItemLink :: ItemGetter String
 getItemLink it =
   case it of
-       -- look up the 'alternate' HTML link relation on the entry:
+       -- look up the 'alternate' HTML link relation on the entry, or one
+       -- without link relation since that is equivalent to 'alternate':
     Feed.AtomItem i -> fmap Atom.linkHref $ listToMaybe $ filter isSelf $ Atom.entryLinks i
     Feed.RSSItem i  -> RSS.rssItemLink i
     Feed.RSS1Item i -> Just (RSS1.itemLink i)
     Feed.XMLItem i  -> fmap (\ ei -> XML.strContent ei) $ findElement (unqual "link") i
  where
-  isSelf lr = toStr (Atom.linkRel lr) == "alternate" && isHTMLType (linkType lr)
+  isSelf lr =
+    let rel = Atom.linkRel lr
+    in  (isNothing rel || toStr rel == "alternate") && isHTMLType (linkType lr)
 
   isHTMLType (Just str) = "lmth" `isPrefixOf` (reverse str)
   isHTMLType _ = True -- if none given, assume html.
diff --git a/tests/Main.hs b/tests/Main.hs
index 6aa492a..e55e42f 100644
--- a/tests/Main.hs
+++ b/tests/Main.hs
@@ -2,9 +2,10 @@ module Main (main) where
 
 import Test.Framework (defaultMain)
 import Text.RSS.Tests (rssTests)
-
+import Text.Atom.Tests (atomTests)
 
 main :: IO ()
-main = defaultMain [
-    rssTests
-    ]
+main = defaultMain
+  [ rssTests
+  , atomTests
+  ]
diff --git a/tests/Text/Atom/Tests.hs b/tests/Text/Atom/Tests.hs
new file mode 100644
index 0000000..96a8dae
--- /dev/null
+++ b/tests/Text/Atom/Tests.hs
@@ -0,0 +1,39 @@
+module Text.Atom.Tests where
+
+import Data.Maybe (isJust)
+import Test.Framework (Test, mutuallyExclusive, testGroup)
+import Test.HUnit (Assertion, assertBool)
+import Test.Framework.Providers.HUnit (testCase)
+import Text.Atom.Feed
+import Text.Feed.Export
+import Text.Feed.Import
+import Text.Feed.Query
+import Text.Feed.Types
+import Text.XML.Light
+
+import Paths_feed
+
+atomTests :: Test
+atomTests = testGroup "Text.Atom"
+    [ mutuallyExclusive $ testGroup "Atom"
+        [ testFullAtomParse
+        , testAtomAlternate
+        ]
+    ]
+
+testFullAtomParse :: Test
+testFullAtomParse = testCase "parse a complete atom file" testAtom
+  where
+    testAtom :: Assertion
+    testAtom = do
+      putStrLn . ppTopElement . xmlFeed =<< parseFeedFromFile =<< getDataFileName "tests/files/atom.xml"
+      assertBool "OK" True
+
+testAtomAlternate :: Test
+testAtomAlternate = testCase "*unspecified* link relation means 'alternate'" testAlt
+  where
+    testAlt :: Assertion
+    testAlt =
+      let nullent = nullEntry "" (TextString "") ""
+          item = AtomItem nullent { entryLinks = [nullLink ""] }
+      in  assertBool "unspecified means alternate" $ isJust $ getItemLink item
diff --git a/tests/files/atom.xml b/tests/files/atom.xml
new file mode 100644
index 0000000..c58181b
--- /dev/null
+++ b/tests/files/atom.xml
@@ -0,0 +1,6733 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<feed xmlns="http://www.w3.org/2005/Atom">
+<title>RecentChanges</title>
+<link href="http://www.rel4tion.org/recentchanges/"/>
+<link href="http://www.rel4tion.org/recentchanges/index.atom" rel="self" type="application/atom+xml"/>
+<author>
+
+<name>Rel4tion</name>
+
+</author>
+
+
+
+
+<id>http://www.rel4tion.org/recentchanges/</id>
+
+<subtitle type="html">Rel4tion</subtitle>
+<generator uri="http://ikiwiki.info/">ikiwiki</generator>
+<updated>2015-09-27T20:04:22Z</updated>
+<entry>
+	<title>change to people/fr33domlover on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_c989bafb33d2bdcd8f01b408f63b7981e62110a9/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-c989bafb33d2bdcd8f01b408f63b7981e62110a9"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-27T20:04:22Z</updated>
+	<published>2015-09-27T20:04:22Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-c989bafb33d2bdcd8f01b408f63b7981e62110a9&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=70e87c497caca5f004d5434a7d6e52b48c01d4f3;hp=2230d818ac803844191d7842bcb24fa4d5e45e14;hb=c989bafb33d2bdcd8f01b408f63b7981e62110a9;hpb=44148b1572c22c8d979bd90a75f82dbe444530df&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;people/fr33domlover&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;08:04:22 PM 09/27/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=c989bafb33d2bdcd8f01b408f63b7981e62110a9&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+me: update paragraph about the open tickets list&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_44148b1572c22c8d979bd90a75f82dbe444530df/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-44148b1572c22c8d979bd90a75f82dbe444530df"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-27T19:58:19Z</updated>
+	<published>2015-09-27T19:58:19Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-44148b1572c22c8d979bd90a75f82dbe444530df&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=ff14943d3018d85e80703df32c9ca2c65c13c83a;hp=d75dd79bb2e9c594f78de4f5897ea7e60d554433;hb=44148b1572c22c8d979bd90a75f82dbe444530df;hpb=1c5f47be50411f5bbcf5b2373d20f6095aeb078f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot&quot; rel=&quot;nofollow&quot;&gt;projects/funbot&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:58:19 PM 09/27/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=44148b1572c22c8d979bd90a75f82dbe444530df&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: mention the helper packages&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to access/paste on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_1c5f47be50411f5bbcf5b2373d20f6095aeb078f/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-1c5f47be50411f5bbcf5b2373d20f6095aeb078f"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-21T17:04:36Z</updated>
+	<published>2015-09-21T17:04:36Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-1c5f47be50411f5bbcf5b2373d20f6095aeb078f&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=access/paste.mdwn;h=118bdeb612c6b61cf5b59c8bd5b8ea7072a61ae8;hp=978504f51469a8aa3ad45c5d55be22ba0503e4ef;hb=1c5f47be50411f5bbcf5b2373d20f6095aeb078f;hpb=681de3e0ea89f8597ea39766be861e70f947793f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=access%2Fpaste&quot; rel=&quot;nofollow&quot;&gt;access/paste&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;05:04:36 PM 09/21/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1c5f47be50411f5bbcf5b2373d20f6095aeb078f&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+access: update URL of paste server code&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_681de3e0ea89f8597ea39766be861e70f947793f/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-681de3e0ea89f8597ea39766be861e70f947793f"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-18T21:39:54Z</updated>
+	<published>2015-09-18T21:39:54Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-681de3e0ea89f8597ea39766be861e70f947793f&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=80ec023c5699abad621d01b1818d39db78ccaed0;hp=da0633c981be6cf4f16c67dea4bf1cba63d2f827;hb=681de3e0ea89f8597ea39766be861e70f947793f;hpb=1e55bf1839b514e0524a294fa62ce0eed46ad3e1&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:39:54 PM 09/18/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=681de3e0ea89f8597ea39766be861e70f947793f&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: mention new dependency, funbot-ext-events&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_1e55bf1839b514e0524a294fa62ce0eed46ad3e1/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-1e55bf1839b514e0524a294fa62ce0eed46ad3e1"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T19:44:49Z</updated>
+	<published>2015-09-17T19:44:49Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-1e55bf1839b514e0524a294fa62ce0eed46ad3e1&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=d75dd79bb2e9c594f78de4f5897ea7e60d554433;hp=f563f5208d711e1946624f45b58eb19e1c8fd688;hb=1e55bf1839b514e0524a294fa62ce0eed46ad3e1;hpb=9abd0dcfc30145da75cd2b246eac79fdd250a57f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:44:49 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1e55bf1839b514e0524a294fa62ce0eed46ad3e1&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: remove dummy text&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_9abd0dcfc30145da75cd2b246eac79fdd250a57f/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-9abd0dcfc30145da75cd2b246eac79fdd250a57f"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T19:43:38Z</updated>
+	<published>2015-09-17T19:43:38Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-9abd0dcfc30145da75cd2b246eac79fdd250a57f&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=f563f5208d711e1946624f45b58eb19e1c8fd688;hp=4648b803378bdbf71232640adf24429bf1e0bf59;hb=9abd0dcfc30145da75cd2b246eac79fdd250a57f;hpb=8b70f13be1209a55b3d31122cba2a8a8a31539ab&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot&quot; rel=&quot;nofollow&quot;&gt;projects/funbot&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:43:38 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=9abd0dcfc30145da75cd2b246eac79fdd250a57f&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: minor update and some dummy test text&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to shortcuts on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_8b70f13be1209a55b3d31122cba2a8a8a31539ab/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-8b70f13be1209a55b3d31122cba2a8a8a31539ab"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T19:22:22Z</updated>
+	<published>2015-09-17T19:22:22Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-8b70f13be1209a55b3d31122cba2a8a8a31539ab&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=shortcuts.mdwn;h=96adf1fbd8cb6601d15184bd5ec1854e262c003b;hp=848c9edfe10d412737a37883ff955dbee20089cb;hb=8b70f13be1209a55b3d31122cba2a8a8a31539ab;hpb=4811a57e33da708175ddd6d016e78bd410f4d1ea&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=shortcuts&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;shortcuts&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:22:22 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=8b70f13be1209a55b3d31122cba2a8a8a31539ab&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+fix notabug shortcut, it shouldn&amp;#39;t url-encode&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/5 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_4811a57e33da708175ddd6d016e78bd410f4d1ea/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-4811a57e33da708175ddd6d016e78bd410f4d1ea"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T13:28:45Z</updated>
+	<published>2015-09-17T13:28:45Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-4811a57e33da708175ddd6d016e78bd410f4d1ea&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=f3c6b11312ebf91ef89c077beb98b475f5f7760c;hp=993dac4b04ed6e9cfc0796f09a90ee568106b193;hb=4811a57e33da708175ddd6d016e78bd410f4d1ea;hpb=07e5d7d13fc364c06ed1bda3f21fa6a493276859&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F5&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/5&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;01:28:45 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=4811a57e33da708175ddd6d016e78bd410f4d1ea&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: close memo ticket&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/2 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_07e5d7d13fc364c06ed1bda3f21fa6a493276859/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-07e5d7d13fc364c06ed1bda3f21fa6a493276859"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T13:22:05Z</updated>
+	<published>2015-09-17T13:22:05Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-07e5d7d13fc364c06ed1bda3f21fa6a493276859&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=58c609b1cc1ffb88ad01aa39806bb43d166f67f9;hp=2cc56bb7968465ca690ebcbed6ed5a5213fb8a0c;hb=07e5d7d13fc364c06ed1bda3f21fa6a493276859;hpb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F2&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;01:22:05 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=07e5d7d13fc364c06ed1bda3f21fa6a493276859&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: close persistence ticket, we have json-state now&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects projects/json-state projects/json-state/decisions projects/json-state/forum projects/json-state/news projects/json-state/releases projects/json-state/tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T13:01:04Z</updated>
+	<published>2015-09-17T13:01:04Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=345421854fa54c60f59686d3908fe58dd4789069;hp=10ae06877f9882b6bd6f3bb1c5b9dd3c7ab032c1;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state.mdwn;h=41137012211445b4f3f48fc8e1c036ababdab2b9;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fjson-state&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/json-state&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/decisions.mdwn;h=87e40f15dec6533bbeebf666fa4d2761c0d5adad;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Fdecisions&quot; rel=&quot;nofollow&quot;&gt;projects/json-state/decisions&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/forum.mdwn;h=cdc6c618a5af5e908dc00cabeed27a4f4d5c9125;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Fforum&quot; rel=&quot;nofollow&quot;&gt;projects/json-state/forum&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/news.mdwn;h=c463308444ec8f91a1bfae7dfda2e5fe3d183863;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Fnews&quot; rel=&quot;nofollow&quot;&gt;projects/json-state/news&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/releases.mdwn;h=e4dcf00f9501d98e461c4a6ccd75818cc54b71fc;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fjson-state%2Freleases&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/json-state/releases&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/tickets.mdwn;h=df2d37627427fe3d89829ad503c725de72c7d762;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Ftickets&quot; rel=&quot;nofollow&quot;&gt;projects/json-state/tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;01:01:04 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+json-state: new project&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/settings projects/settings/releases on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_8271123effea28344517c121ee596eb7217e28e2/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-8271123effea28344517c121ee596eb7217e28e2"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T12:59:24Z</updated>
+	<published>2015-09-17T12:59:24Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-8271123effea28344517c121ee596eb7217e28e2&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings.mdwn;h=be444e1b1ee23712cdb25e2d3fa155319dd04b38;hp=b7f5ffc7ee35f85a7a7d5094fdc02c578122825e;hb=8271123effea28344517c121ee596eb7217e28e2;hpb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/settings&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/releases.mdwn;h=4c6c784b8ea0ca05ff9fd5232a2a195159aa4cae;hp=e4efd9b315242da6e04f9e94546ed3522bdaac68;hb=8271123effea28344517c121ee596eb7217e28e2;hpb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Freleases&quot; rel=&quot;nofollow&quot;&gt;projects/settings/releases&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:59:24 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=8271123effea28344517c121ee596eb7217e28e2&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+settings: update repo link&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/15 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_9bd1e350a4f81d79b820eb5a1ab3e644a280399a/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-9bd1e350a4f81d79b820eb5a1ab3e644a280399a"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-17T11:51:13Z</updated>
+	<published>2015-09-17T11:51:13Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a6aef60136eb5939cd49fe3dff12a23214f96914;hp=37a1b5e2695ce312b8f1b8e37078dd4cdbc90898;hb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a;hpb=edabc8116457185ce07d1f61737fa2ce8518bd4b&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:51:13 AM 09/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: settings system is finally complete&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/manual on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_edabc8116457185ce07d1f61737fa2ce8518bd4b/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-edabc8116457185ce07d1f61737fa2ce8518bd4b"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-16T19:04:22Z</updated>
+	<published>2015-09-16T19:04:22Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-edabc8116457185ce07d1f61737fa2ce8518bd4b&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=d098b5370a8cbf0e60f80e37f23276dda4f2afd1;hp=56ff43060cd3eecca2eb10237bc7303d1ecc8652;hb=edabc8116457185ce07d1f61737fa2ce8518bd4b;hpb=37ec11668e6a6a9418209c5411508d018592519d&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fmanual&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:04:22 PM 09/16/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=edabc8116457185ce07d1f61737fa2ce8518bd4b&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update manual with recent changes&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to people/fr33domlover/blog/love-of-wisdom on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_37ec11668e6a6a9418209c5411508d018592519d/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-37ec11668e6a6a9418209c5411508d018592519d"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-12T13:12:06Z</updated>
+	<published>2015-09-12T13:12:06Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-37ec11668e6a6a9418209c5411508d018592519d&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/love-of-wisdom.mdwn;h=a9bfd88c473fc20270af0a83570f8a4b70d12691;hp=0000000000000000000000000000000000000000;hb=37ec11668e6a6a9418209c5411508d018592519d;hpb=29d3a9e5554fb2ea6987f31f968578cc2647e8f3&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover%2Fblog%2Flove-of-wisdom&quot; rel=&quot;nofollow&quot;&gt;people/fr33domlover/blog/love-of-wisdom&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;01:12:06 PM 09/12/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=37ec11668e6a6a9418209c5411508d018592519d&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+me: another blog post...&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to news/break on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_29d3a9e5554fb2ea6987f31f968578cc2647e8f3/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-29d3a9e5554fb2ea6987f31f968578cc2647e8f3"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-10T22:01:02Z</updated>
+	<published>2015-09-10T22:01:02Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-29d3a9e5554fb2ea6987f31f968578cc2647e8f3&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=news/break.mdwn;h=5eb7a858b10923cf2973d7b6004cb2c1783bea45;hp=0000000000000000000000000000000000000000;hb=29d3a9e5554fb2ea6987f31f968578cc2647e8f3;hpb=34a21b40a95051a6bee7f3c89223b868ebcb64ac&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=news%2Fbreak&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;news/break&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:01:02 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=29d3a9e5554fb2ea6987f31f968578cc2647e8f3&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+news: break&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to index on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_34a21b40a95051a6bee7f3c89223b868ebcb64ac/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-34a21b40a95051a6bee7f3c89223b868ebcb64ac"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-10T21:50:12Z</updated>
+	<published>2015-09-10T21:50:12Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-34a21b40a95051a6bee7f3c89223b868ebcb64ac&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=index.mdwn;h=c68cb36b6224504f98fe4811e08c49a1b07f2df0;hp=126fe28b2815f6a3d4a3095dd5e11485cebb8086;hb=34a21b40a95051a6bee7f3c89223b868ebcb64ac;hpb=ed2a95c268ef060d9dddae5a24b4672911491c72&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=index&quot; rel=&quot;nofollow&quot;&gt;index&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:50:12 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=34a21b40a95051a6bee7f3c89223b868ebcb64ac&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+index: remove feedback box&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/manual on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_ed2a95c268ef060d9dddae5a24b4672911491c72/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-ed2a95c268ef060d9dddae5a24b4672911491c72"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-10T18:46:34Z</updated>
+	<published>2015-09-10T18:46:34Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-ed2a95c268ef060d9dddae5a24b4672911491c72&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=56ff43060cd3eecca2eb10237bc7303d1ecc8652;hp=44c3d463280d7e275a6f93bd9633289f0872b686;hb=ed2a95c268ef060d9dddae5a24b4672911491c72;hpb=d3cdcea02b8dedede9d590ff8a730cac95a10c58&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;06:46:34 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=ed2a95c268ef060d9dddae5a24b4672911491c72&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: revise manual&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/5 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_d3cdcea02b8dedede9d590ff8a730cac95a10c58/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-d3cdcea02b8dedede9d590ff8a730cac95a10c58"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-09-10T13:16:52Z</updated>
+	<published>2015-09-10T13:16:52Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-d3cdcea02b8dedede9d590ff8a730cac95a10c58&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=993dac4b04ed6e9cfc0796f09a90ee568106b193;hp=606f28657913248cbfe3204aa6f0ffebec656b55;hb=d3cdcea02b8dedede9d590ff8a730cac95a10c58;hpb=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F5&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/5&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;01:16:52 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=d3cdcea02b8dedede9d590ff8a730cac95a10c58&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: document work on memos&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/18 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-31T17:35:31Z</updated>
+	<published>2015-08-31T17:35:31Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=92ddfe617ac1113a7b96d24857c5e783f55432aa;hp=d9fbdf7bd75e3ce0638d56f2bae98e47270b7baa;hb=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2;hpb=74c8029879813f445632d74c6b0233496729a757&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F18&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/18&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;05:35:31 PM 08/31/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: document progress on friendly command access&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/18 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_74c8029879813f445632d74c6b0233496729a757/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-74c8029879813f445632d74c6b0233496729a757"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-30T16:31:13Z</updated>
+	<published>2015-08-30T16:31:13Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-74c8029879813f445632d74c6b0233496729a757&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=d9fbdf7bd75e3ce0638d56f2bae98e47270b7baa;hp=f717e312738110e9fa51874c4efa2b918dca6c43;hb=74c8029879813f445632d74c6b0233496729a757;hpb=2f15a1e3784ca2c076afb2654bb313723de8592e&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F18&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/18&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;04:31:13 PM 08/30/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=74c8029879813f445632d74c6b0233496729a757&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: plan API for friendly command access&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_2f15a1e3784ca2c076afb2654bb313723de8592e/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-2f15a1e3784ca2c076afb2654bb313723de8592e"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-28T21:39:21Z</updated>
+	<published>2015-08-28T21:39:21Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-2f15a1e3784ca2c076afb2654bb313723de8592e&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=da0633c981be6cf4f16c67dea4bf1cba63d2f827;hp=bb59f3668fc21acdb2072022cb65808df5becebd;hb=2f15a1e3784ca2c076afb2654bb313723de8592e;hpb=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:39:21 PM 08/28/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2f15a1e3784ca2c076afb2654bb313723de8592e&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update guide to explain new state files&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/15 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_60f4a8590a34861a966b85ad8d7e6c9c8daa7ace/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-60f4a8590a34861a966b85ad8d7e6c9c8daa7ace"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-24T19:45:05Z</updated>
+	<published>2015-08-24T19:45:05Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-60f4a8590a34861a966b85ad8d7e6c9c8daa7ace&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=37a1b5e2695ce312b8f1b8e37078dd4cdbc90898;hp=a466fadce2c88cde0347c164e7a49c97e32e1b13;hb=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace;hpb=d0ab67c9ff7643ac75e918e3cb295288003e47e4&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:45:05 PM 08/24/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: settings now support exploration&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/18 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_d0ab67c9ff7643ac75e918e3cb295288003e47e4/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-d0ab67c9ff7643ac75e918e3cb295288003e47e4"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-23T22:01:20Z</updated>
+	<published>2015-08-23T22:01:20Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-d0ab67c9ff7643ac75e918e3cb295288003e47e4&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=f717e312738110e9fa51874c4efa2b918dca6c43;hp=0000000000000000000000000000000000000000;hb=d0ab67c9ff7643ac75e918e3cb295288003e47e4;hpb=6e90ed1b9fa935727054984b9252bd79a5dbef6b&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F18&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/18&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:01:20 PM 08/23/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=d0ab67c9ff7643ac75e918e3cb295288003e47e4&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: new ticket: intuitive UI&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/settings/tickets/1 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_6e90ed1b9fa935727054984b9252bd79a5dbef6b/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-6e90ed1b9fa935727054984b9252bd79a5dbef6b"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-23T21:49:11Z</updated>
+	<published>2015-08-23T21:49:11Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-6e90ed1b9fa935727054984b9252bd79a5dbef6b&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=e666ba63a41d9c574d63f73f8e85316a165aa6f9;hp=1212dbea4050efc9f0e06f61ea832babb70099ed;hb=6e90ed1b9fa935727054984b9252bd79a5dbef6b;hpb=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets%2F1&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:49:11 PM 08/23/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=6e90ed1b9fa935727054984b9252bd79a5dbef6b&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+settings: close #1, callbacks and save/load added&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-23T19:23:22Z</updated>
+	<published>2015-08-23T19:23:22Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=bb59f3668fc21acdb2072022cb65808df5becebd;hp=70eb2c6b749d1499807a21e0bc4a6ef2614f90a4;hb=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa;hpb=6f734bfda528f1afb249d33bb438a7a5638f3ad1&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:23:22 PM 08/23/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: explain about settings in the guide&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/settings/tickets/1 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_6f734bfda528f1afb249d33bb438a7a5638f3ad1/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-6f734bfda528f1afb249d33bb438a7a5638f3ad1"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-23T09:49:55Z</updated>
+	<published>2015-08-23T09:49:55Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-6f734bfda528f1afb249d33bb438a7a5638f3ad1&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=1212dbea4050efc9f0e06f61ea832babb70099ed;hp=83d3c27561e380877f7214159378ff806b206b2c;hb=6f734bfda528f1afb249d33bb438a7a5638f3ad1;hpb=428482ea05956bcfebaaa68abeb9cdc1105ed129&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Ftickets%2F1&quot; rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:49:55 AM 08/23/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=6f734bfda528f1afb249d33bb438a7a5638f3ad1&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+settings: plan custom debounce action for saving&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to people/fr33domlover/blog/insanity2 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_428482ea05956bcfebaaa68abeb9cdc1105ed129/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-428482ea05956bcfebaaa68abeb9cdc1105ed129"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-23T09:49:16Z</updated>
+	<published>2015-08-23T09:49:16Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-428482ea05956bcfebaaa68abeb9cdc1105ed129&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/insanity2.mdwn;h=9746b62a83126b3a142ff7d067de559441e39a00;hp=0000000000000000000000000000000000000000;hb=428482ea05956bcfebaaa68abeb9cdc1105ed129;hpb=67577535d19a1fcd1c187d71f41aa012a16d65f3&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fblog%2Finsanity2&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;people/fr33domlover/blog/insanity2&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:49:16 AM 08/23/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=428482ea05956bcfebaaa68abeb9cdc1105ed129&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+blog post...&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/settings/tickets/1 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_67577535d19a1fcd1c187d71f41aa012a16d65f3/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-67577535d19a1fcd1c187d71f41aa012a16d65f3"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-22T00:42:25Z</updated>
+	<published>2015-08-22T00:42:25Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-67577535d19a1fcd1c187d71f41aa012a16d65f3&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=83d3c27561e380877f7214159378ff806b206b2c;hp=6a63447c56eaeca30431fad77cb1945230f73ac7;hb=67577535d19a1fcd1c187d71f41aa012a16d65f3;hpb=f4aaab3a133c556a0db208924e86bbb312879319&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Ftickets%2F1&quot; rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:42:25 AM 08/22/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=67577535d19a1fcd1c187d71f41aa012a16d65f3&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+settings: work on callbacks and persistence&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/settings/tickets/1 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_f4aaab3a133c556a0db208924e86bbb312879319/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-f4aaab3a133c556a0db208924e86bbb312879319"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-21T14:20:30Z</updated>
+	<published>2015-08-21T14:20:30Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-f4aaab3a133c556a0db208924e86bbb312879319&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=6a63447c56eaeca30431fad77cb1945230f73ac7;hp=0000000000000000000000000000000000000000;hb=f4aaab3a133c556a0db208924e86bbb312879319;hpb=2e457435020f1ab3b5836e8efb3cc1228c6b595c&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets%2F1&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;02:20:30 PM 08/21/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=f4aaab3a133c556a0db208924e86bbb312879319&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+settings: new ticket: scope and features&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects projects/feed-collect projects/feed-collect/decisions projects/feed-collect/forum projects/feed-collect/news projects/feed-collect/releases projects/feed-collect/tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_2e457435020f1ab3b5836e8efb3cc1228c6b595c/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-2e457435020f1ab3b5836e8efb3cc1228c6b595c"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-19T10:02:40Z</updated>
+	<published>2015-08-19T10:02:40Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-2e457435020f1ab3b5836e8efb3cc1228c6b595c&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=10ae06877f9882b6bd6f3bb1c5b9dd3c7ab032c1;hp=898655fcc20c4302682ffe196aa54e3afeb59b36;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect.mdwn;h=6c574d38ef834e36a9a9be69bfcff3a6598fe461;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/feed-collect&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/decisions.mdwn;h=ae1b64118c25d3e7236d3f239dfb9c423225532a;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffeed-collect%2Fdecisions&quot; rel=&quot;nofollow&quot;&gt;projects/feed-collect/decisions&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/forum.mdwn;h=21ae61a8f6c6c15ac9fc7d1776599bddbb66bd39;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Fforum&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/feed-collect/forum&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/news.mdwn;h=b7a2df9ac1e94ba97e0bfbcc56d346a153ad78f1;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Fnews&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/feed-collect/news&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/releases.mdwn;h=1bf09d72d75f6bce0cf32b591d5fb6245c99d4c9;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Freleases&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/feed-collect/releases&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/tickets.mdwn;h=99f8e90067ef5c1404674843969b71e2184721aa;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Ftickets&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/feed-collect/tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:02:40 AM 08/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2e457435020f1ab3b5836e8efb3cc1228c6b595c&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+feed-collect: new project (actually about to release)&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/6 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_e127857268e2b2c8181245b6693205c98f371648/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-e127857268e2b2c8181245b6693205c98f371648"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-18T17:06:48Z</updated>
+	<published>2015-08-18T17:06:48Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-e127857268e2b2c8181245b6693205c98f371648&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/6.mdwn;h=572dde578082b3005aa3534ed3c0a7f92f21f7b3;hp=bffd53261a36337edc4988f732b733d1996f6e5c;hb=e127857268e2b2c8181245b6693205c98f371648;hpb=1f86b06ce5d3930dc77991312d02cba3193084f6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F6&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/6&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;05:06:48 PM 08/18/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=e127857268e2b2c8181245b6693205c98f371648&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+fix invalid link&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/6 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_1f86b06ce5d3930dc77991312d02cba3193084f6/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-1f86b06ce5d3930dc77991312d02cba3193084f6"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-18T14:54:20Z</updated>
+	<published>2015-08-18T14:54:20Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-1f86b06ce5d3930dc77991312d02cba3193084f6&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/6.mdwn;h=bffd53261a36337edc4988f732b733d1996f6e5c;hp=685bde0ac57f25f9a469350985154c13330ccf1e;hb=1f86b06ce5d3930dc77991312d02cba3193084f6;hpb=d2bcaf67089dbb1b92c2128b23134e48597ed455&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F6&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/6&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;02:54:20 PM 08/18/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1f86b06ce5d3930dc77991312d02cba3193084f6&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update status of freepost integration&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/4 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_d2bcaf67089dbb1b92c2128b23134e48597ed455/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-d2bcaf67089dbb1b92c2128b23134e48597ed455"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-18T14:02:57Z</updated>
+	<published>2015-08-18T14:02:57Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-d2bcaf67089dbb1b92c2128b23134e48597ed455&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/4.mdwn;h=ff2a4540311b77cfbad57c95b57a2090b7eedb9b;hp=071cb7e64ae57c211834ee5cc7e80132209a6bc2;hb=d2bcaf67089dbb1b92c2128b23134e48597ed455;hpb=b61f7736931f2801c6fdd401f29f6fc78b2d900a&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F4&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/4&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;02:02:57 PM 08/18/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=d2bcaf67089dbb1b92c2128b23134e48597ed455&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: notes on coding of logging system&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/16 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_b61f7736931f2801c6fdd401f29f6fc78b2d900a/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-b61f7736931f2801c6fdd401f29f6fc78b2d900a"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-17T09:12:02Z</updated>
+	<published>2015-08-17T09:12:02Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-b61f7736931f2801c6fdd401f29f6fc78b2d900a&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=1197b4650734456f81f92dfd314c5a076bb5762c;hp=15bbe0cb556feb7ed9000c36bb42a8396fb12921;hb=b61f7736931f2801c6fdd401f29f6fc78b2d900a;hpb=a9301fc50b752e55af343255a0b54b990646bd43&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F16&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/16&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:12:02 AM 08/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=b61f7736931f2801c6fdd401f29f6fc78b2d900a&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: close #16, feed reader implemented&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/17 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_a9301fc50b752e55af343255a0b54b990646bd43/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-a9301fc50b752e55af343255a0b54b990646bd43"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-17T09:09:36Z</updated>
+	<published>2015-08-17T09:09:36Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-a9301fc50b752e55af343255a0b54b990646bd43&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/17.mdwn;h=7502e27ea78f3f9667ccdad47b77914d283502d2;hp=70f51944ac387924b6f8bf7433631a3baeb038a4;hb=a9301fc50b752e55af343255a0b54b990646bd43;hpb=360a6d980da581e86d5fe7a80c1fa059b668ab93&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F17&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/17&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:09:36 AM 08/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=a9301fc50b752e55af343255a0b54b990646bd43&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: close #17, the bot should spam less now&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/10 projects/irc-fun-bot/tickets/3 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_360a6d980da581e86d5fe7a80c1fa059b668ab93/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-360a6d980da581e86d5fe7a80c1fa059b668ab93"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-17T00:39:34Z</updated>
+	<published>2015-08-17T00:39:34Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-360a6d980da581e86d5fe7a80c1fa059b668ab93&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=f267e06c2e4ba2d221a5e8b493e7d83954a86b98;hp=2dfa6c5aa076d72de618c647a17774e23cacf78f;hb=360a6d980da581e86d5fe7a80c1fa059b668ab93;hpb=f7b4fd5b731cb17a6489352f10a735368f34d46d&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F10&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/10&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=ca2600e82be6faed8128f2e92e37f7941fc25415;hp=cf324dd4a0534fb640a72e516a58205b01917e28;hb=360a6d980da581e86d5fe7a80c1fa059b668ab93;hpb=f7b4fd5b731cb17a6489352f10a735368f34d46d&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F3&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/3&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:39:34 AM 08/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=360a6d980da581e86d5fe7a80c1fa059b668ab93&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: close tickets done with&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide projects/funbot/manual on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_f7b4fd5b731cb17a6489352f10a735368f34d46d/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-f7b4fd5b731cb17a6489352f10a735368f34d46d"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-16T22:15:37Z</updated>
+	<published>2015-08-16T22:15:37Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-f7b4fd5b731cb17a6489352f10a735368f34d46d&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=70eb2c6b749d1499807a21e0bc4a6ef2614f90a4;hp=85e000a7ff584f162078086dd4c4a2a4fd960028;hb=f7b4fd5b731cb17a6489352f10a735368f34d46d;hpb=599eada420921192ceae6cb687f8a9950022044f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=44c3d463280d7e275a6f93bd9633289f0872b686;hp=b67467c06eb95e96e22c9645100359f147b32ad1;hb=f7b4fd5b731cb17a6489352f10a735368f34d46d;hpb=599eada420921192ceae6cb687f8a9950022044f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:15:37 PM 08/16/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=f7b4fd5b731cb17a6489352f10a735368f34d46d&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update docs&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/15 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_599eada420921192ceae6cb687f8a9950022044f/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-599eada420921192ceae6cb687f8a9950022044f"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-16T18:43:49Z</updated>
+	<published>2015-08-16T18:43:49Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-599eada420921192ceae6cb687f8a9950022044f&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a466fadce2c88cde0347c164e7a49c97e32e1b13;hp=9fde6e22407a2eff47b1a666b3d3c274e5e19859;hb=599eada420921192ceae6cb687f8a9950022044f;hpb=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;06:43:49 PM 08/16/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=599eada420921192ceae6cb687f8a9950022044f&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: the settings system needs callbacks&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/17 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_2bf9de01bb378e4c9ed11cb7799ee03f12aed21b/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-2bf9de01bb378e4c9ed11cb7799ee03f12aed21b"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-15T10:34:40Z</updated>
+	<published>2015-08-15T10:34:40Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-2bf9de01bb378e4c9ed11cb7799ee03f12aed21b&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/17.mdwn;h=70f51944ac387924b6f8bf7433631a3baeb038a4;hp=0000000000000000000000000000000000000000;hb=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b;hpb=0e840edc3dd9ec79ee219ba94cd63866eed668ea&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F17&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/17&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:34:40 AM 08/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: new ticket: avoid spamming with multi-commit pushes&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/16 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_0e840edc3dd9ec79ee219ba94cd63866eed668ea/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-0e840edc3dd9ec79ee219ba94cd63866eed668ea"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-13T16:57:09Z</updated>
+	<published>2015-08-13T16:57:09Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-0e840edc3dd9ec79ee219ba94cd63866eed668ea&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=15bbe0cb556feb7ed9000c36bb42a8396fb12921;hp=e62242d40f027b0491185be804ed929dc5a4ac7f;hb=0e840edc3dd9ec79ee219ba94cd63866eed668ea;hpb=f8d63be6c0d9119296673fb426e4a67f514397e0&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F16&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/16&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;04:57:09 PM 08/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=0e840edc3dd9ec79ee219ba94cd63866eed668ea&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: list existing feed related packages to review&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/16 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_f8d63be6c0d9119296673fb426e4a67f514397e0/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-f8d63be6c0d9119296673fb426e4a67f514397e0"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-13T07:23:09Z</updated>
+	<published>2015-08-13T07:23:09Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-f8d63be6c0d9119296673fb426e4a67f514397e0&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=e62242d40f027b0491185be804ed929dc5a4ac7f;hp=0000000000000000000000000000000000000000;hb=f8d63be6c0d9119296673fb426e4a67f514397e0;hpb=5b11daceee3ab50b30197cfa2ab5385b24a8dc73&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F16&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/16&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:23:09 AM 08/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=f8d63be6c0d9119296673fb426e4a67f514397e0&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: new ticket: announce RSS feeds&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to people/fr33domlover/veganism on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_5b11daceee3ab50b30197cfa2ab5385b24a8dc73/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-5b11daceee3ab50b30197cfa2ab5385b24a8dc73"/>
+
+	<author><name>mm</name></author>
+
+
+
+
+
+	<updated>2015-08-13T03:23:02Z</updated>
+	<published>2015-08-13T03:23:02Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-5b11daceee3ab50b30197cfa2ab5385b24a8dc73&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/veganism.mdwn;h=b129c47a62a42f0e7094ea66ab4120c70bbf2956;hp=531aa72c9aa9be7cec113b57f7cd0792bd873cc4;hb=5b11daceee3ab50b30197cfa2ab5385b24a8dc73;hpb=bb1d1469396d107bdbbe314e87d3666cf530d297&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fveganism&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;people/fr33domlover/veganism&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Fmm&quot; rel=&quot;nofollow&quot;&gt;mm&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;web&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;03:23:02 AM 08/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=5b11daceee3ab50b30197cfa2ab5385b24a8dc73&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects projects/vcs-web-hook-parse projects/vcs-web-hook-parse/tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_bb1d1469396d107bdbbe314e87d3666cf530d297/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-bb1d1469396d107bdbbe314e87d3666cf530d297"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-10T13:29:45Z</updated>
+	<published>2015-08-10T13:29:45Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-bb1d1469396d107bdbbe314e87d3666cf530d297&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=898655fcc20c4302682ffe196aa54e3afeb59b36;hp=8dc1b5dc39e41e5367ca9ba74882e13effdd2e49;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects&quot; rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vcs-web-hook-parse.mdwn;h=5128a0066c64cf95ed693d43e4b463adad27e2cb;hp=0000000000000000000000000000000000000000;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fvcs-web-hook-parse&quot; rel=&quot;nofollow&quot;&gt;projects/vcs-web-hook-parse&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vcs-web-hook-parse/tickets.mdwn;h=5dea4f6f5c1bd6d7879c5773f8015c408511e55f;hp=0000000000000000000000000000000000000000;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fvcs-web-hook-parse%2Ftickets&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/vcs-web-hook-parse/tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;01:29:45 PM 08/10/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=bb1d1469396d107bdbbe314e87d3666cf530d297&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+vcs-web-hook-parse: new project, added dummy pages&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide projects/irc-fun-bot projects/irc-fun-client projects/irc-fun-messages on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_a815429ee204e00c48a0d72cc17456246e6040de/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-a815429ee204e00c48a0d72cc17456246e6040de"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-09T14:20:44Z</updated>
+	<published>2015-08-09T14:20:44Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-a815429ee204e00c48a0d72cc17456246e6040de&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=85e000a7ff584f162078086dd4c4a2a4fd960028;hp=fe77d4628d012fbba69fb4186054141ac9386e1e;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot.mdwn;h=d16135bd1e6a372261567b700c147259d4e0f6af;hp=bbd523480202c43f2ad9cb96773d69fa16a29819;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-client.mdwn;h=cdac524a07d2eb092f858de8d4d8d8a0cfc0e8d7;hp=052a1471d2b01e04b9a250bd3ce5efda48e973e8;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-client&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-client&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages.mdwn;h=b793f23214f70270ed7da5b3699ad9efdabb5e77;hp=8a037a6b3176f58e7585d9442b98292313fca511;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;02:20:44 PM 08/09/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=a815429ee204e00c48a0d72cc17456246e6040de&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update repo links after move to dev.&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/rel4tion/roadmap/release-00 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_63c70b3be856df4c006fabdafb301f9f47fa0b42/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-63c70b3be856df4c006fabdafb301f9f47fa0b42"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-09T12:25:39Z</updated>
+	<published>2015-08-09T12:25:39Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-63c70b3be856df4c006fabdafb301f9f47fa0b42&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/rel4tion/roadmap/release-00.mdwn;h=ce02ef19c8176eb80c1fd5ca77cacfd6ef42a296;hp=b0297d9c7d79acf1fb70bf3029570491f97470c0;hb=63c70b3be856df4c006fabdafb301f9f47fa0b42;hpb=4114d7f291fe124c5169e1588bf3ba8828ea1955&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Frel4tion%2Froadmap%2Frelease-00&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/rel4tion/roadmap/release-00&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:25:39 PM 08/09/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=63c70b3be856df4c006fabdafb301f9f47fa0b42&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+rel4tion: update roadmap with recent work&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/rmtask on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_4114d7f291fe124c5169e1588bf3ba8828ea1955/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-4114d7f291fe124c5169e1588bf3ba8828ea1955"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-09T11:34:25Z</updated>
+	<published>2015-08-09T11:34:25Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-4114d7f291fe124c5169e1588bf3ba8828ea1955&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/rmtask.mdwn;h=e8a5548bd50de46c670e181aa5ab4af0b53336a5;hp=8081803ab94e9f415a0b16ddd06345163bda3541;hb=4114d7f291fe124c5169e1588bf3ba8828ea1955;hpb=a388b2d06814991f93f52276b8dfe18cd1627ef1&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Frmtask&quot; rel=&quot;nofollow&quot;&gt;templates/rmtask&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:34:25 AM 08/09/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=4114d7f291fe124c5169e1588bf3ba8828ea1955&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+templates: tweak rmtask colors&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide projects/funbot/manual projects/funbot/tickets/7 projects/irc-fun-bot/tickets/3 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_a388b2d06814991f93f52276b8dfe18cd1627ef1/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-a388b2d06814991f93f52276b8dfe18cd1627ef1"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-08T22:47:46Z</updated>
+	<published>2015-08-08T22:47:46Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-a388b2d06814991f93f52276b8dfe18cd1627ef1&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=fe77d4628d012fbba69fb4186054141ac9386e1e;hp=6234c5babf562a6e0554c81171beb169c721b6de;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=b67467c06eb95e96e22c9645100359f147b32ad1;hp=4fb784a3bbd9efa372438f998917e996c95946d6;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/7.mdwn;h=24801b7b18518348ed77f49239ab071f106fe4ab;hp=edc5905349f54c32ce471d98c1434723aca026d5;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F7&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/7&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=cf324dd4a0534fb640a72e516a58205b01917e28;hp=7ad03fd86056bf4892a412a1fc7c85838a36d170;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F3&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/3&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:47:46 PM 08/08/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=a388b2d06814991f93f52276b8dfe18cd1627ef1&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: ticket and doc updates&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/2 projects/http-listen/tickets/2 projects/irc-fun-bot/tickets/3 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_5f028255a061f5e1405aae1f4bcf911086ddc4d9/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-5f028255a061f5e1405aae1f4bcf911086ddc4d9"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-06T13:37:56Z</updated>
+	<published>2015-08-06T13:37:56Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=2cc56bb7968465ca690ebcbed6ed5a5213fb8a0c;hp=2db571641ae6d30d6d74d401e2e96015b833b811;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F2&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets/2.mdwn;h=083e030badb159f80bb13af5c2ec169c24e4874e;hp=0000000000000000000000000000000000000000;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fhttp-listen%2Ftickets%2F2&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen/tickets/2&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=7ad03fd86056bf4892a412a1fc7c85838a36d170;hp=9a3b0698a4094f4fdc31af182d9233e45bdd5928;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F3&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/3&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;01:37:56 PM 08/06/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+some ticket updates&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/http-listen/tickets/1 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_c5b0bd2d44344346599c272f5f9f089cff3cd0cf/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-c5b0bd2d44344346599c272f5f9f089cff3cd0cf"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-05T09:52:09Z</updated>
+	<published>2015-08-05T09:52:09Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets/1.mdwn;h=0798820f782a817d904c7c077c4a2395ec33c171;hp=0000000000000000000000000000000000000000;hb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf;hpb=abccb345fea04b01b45eed2a0f56c3c88988ebf0&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Ftickets%2F1&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen/tickets/1&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:52:09 AM 08/05/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+http-listen: ope ticket about timeouts&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects projects/http-listen projects/http-listen/decisions projects/http-listen/forum projects/http-listen/news projects/http-listen/releases projects/http-listen/tickets shortcuts on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_abccb345fea04b01b45eed2a0f56c3c88988ebf0/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-abccb345fea04b01b45eed2a0f56c3c88988ebf0"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-05T09:23:20Z</updated>
+	<published>2015-08-05T09:23:20Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-abccb345fea04b01b45eed2a0f56c3c88988ebf0&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=8dc1b5dc39e41e5367ca9ba74882e13effdd2e49;hp=8a382bc0b1a8668b14aad89aa4bc16711a1ed84a;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects&quot; rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen.mdwn;h=7034ea4798f3d24ebcebd4c02cdd3865c245924d;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/decisions.mdwn;h=1a96e79ec55bb6bb817136a2ee3c333e4bbf4c36;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fhttp-listen%2Fdecisions&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen/decisions&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/forum.mdwn;h=b4032d88892110263de936a7f9ef6c7f8f7d755b;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Fforum&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen/forum&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/news.mdwn;h=a52d3fd6fc03f44418a4db0ccd745b3f53d6d81d;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fhttp-listen%2Fnews&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen/news&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/releases.mdwn;h=36687b2803485acb11d99138e4b5d9b1d40a177a;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Freleases&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen/releases&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets.mdwn;h=36e5aefaceccf9996d9dcf98239267d20c895455;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Ftickets&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/http-listen/tickets&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=shortcuts.mdwn;h=848c9edfe10d412737a37883ff955dbee20089cb;hp=955fe6213cd0b74a022cb19d9a82986422a5ac7c;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=shortcuts&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;shortcuts&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:23:20 AM 08/05/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=abccb345fea04b01b45eed2a0f56c3c88988ebf0&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+http-listen: new project&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/kiwi/data/idan-files/todo.idan on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_3807c6e1a57de56dd0e0502a1fe7020d089048c5/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-3807c6e1a57de56dd0e0502a1fe7020d089048c5"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-01T21:21:43Z</updated>
+	<published>2015-08-01T21:21:43Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/kiwi/data/idan-files/todo.idan;h=ccb6b70db2f4b5da7fa5d3a70c1ddc8cd9f1a33e;hp=eace9d20f6dd5d83087bc751aead7446aca7e575;hb=3807c6e1a57de56dd0e0502a1fe7020d089048c5;hpb=dd747340fffdb41ba4ff5066356b22dbffd73c98&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fkiwi%2Fdata%2Fidan-files%2Ftodo.idan&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/kiwi/data/idan-files/todo.idan&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:21:43 PM 08/01/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=3807c6e1a57de56dd0e0502a1fe7020d089048c5&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+kiwi: tasks-tui requires new entities&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to news/darcs-hub-new on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_dd747340fffdb41ba4ff5066356b22dbffd73c98/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-dd747340fffdb41ba4ff5066356b22dbffd73c98"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-08-01T11:35:10Z</updated>
+	<published>2015-08-01T11:35:10Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-dd747340fffdb41ba4ff5066356b22dbffd73c98&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=news/darcs-hub-new.mdwn;h=d1cbc5d5d35452c5272006db744779409c9b8505;hp=0000000000000000000000000000000000000000;hb=dd747340fffdb41ba4ff5066356b22dbffd73c98;hpb=65c40fbb77b5f797a67493716418ed0115a160cf&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=news%2Fdarcs-hub-new&quot; rel=&quot;nofollow&quot;&gt;news/darcs-hub-new&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:35:10 AM 08/01/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=dd747340fffdb41ba4ff5066356b22dbffd73c98&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+news: new darcs hub&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/vocabularies-hs on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_65c40fbb77b5f797a67493716418ed0115a160cf/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-65c40fbb77b5f797a67493716418ed0115a160cf"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-31T08:44:15Z</updated>
+	<published>2015-07-31T08:44:15Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-65c40fbb77b5f797a67493716418ed0115a160cf&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vocabularies-hs.mdwn;h=a21d0e3f8540fe73f4e9591a313c911aed6e6252;hp=c56d2d47ee0fe9de02ef44b045edc516cfe756e6;hb=65c40fbb77b5f797a67493716418ed0115a160cf;hpb=f0986cdfd3174159052ac1d3da6e1180dfb9a644&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fvocabularies-hs&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/vocabularies-hs&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;08:44:15 AM 07/31/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=65c40fbb77b5f797a67493716418ed0115a160cf&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+vocabularies-hs: list the new vocabulary-todo&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/kiwi/data/idan-files/todo.idan on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_f0986cdfd3174159052ac1d3da6e1180dfb9a644/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-f0986cdfd3174159052ac1d3da6e1180dfb9a644"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-29T23:28:20Z</updated>
+	<published>2015-07-29T23:28:20Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-f0986cdfd3174159052ac1d3da6e1180dfb9a644&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/kiwi/data/idan-files/todo.idan;h=eace9d20f6dd5d83087bc751aead7446aca7e575;hp=9dd53e5a54d1add44987b39afc376c6d16a2e467;hb=f0986cdfd3174159052ac1d3da6e1180dfb9a644;hpb=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fkiwi%2Fdata%2Fidan-files%2Ftodo.idan&quot; rel=&quot;nofollow&quot;&gt;projects/kiwi/data/idan-files/todo.idan&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:28:20 PM 07/29/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=f0986cdfd3174159052ac1d3da6e1180dfb9a644&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+kiwi: manually add uids needed for coding&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/task-management on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-29T21:09:24Z</updated>
+	<published>2015-07-29T21:09:24Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management.mdwn;h=852b193c67147e825e7426c09906641acf1dc5fa;hp=1f188daada9a5897e3bd452afbf20e11b08a9c01;hb=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da;hpb=696ceb85012bff250079824aa5ccf4b526031427&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management&quot; rel=&quot;nofollow&quot;&gt;projects/task-management&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:09:24 PM 07/29/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+task-management: update project status&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/task-management/tickets/1 projects/task-management/tickets/1/operations projects/task-management/tickets/1/possible-features projects/task-management/tickets/1/ui projects/task-management/tickets/1/views projects/tui on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_696ceb85012bff250079824aa5ccf4b526031427/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-696ceb85012bff250079824aa5ccf4b526031427"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-29T06:51:46Z</updated>
+	<published>2015-07-29T06:51:46Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-696ceb85012bff250079824aa5ccf4b526031427&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1.mdwn;h=e1a899675f53d52ee329abd44daf3a99c7f10cad;hp=1e660face13843a722026d94ec4c2f51b2160069;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/operations.mdwn;h=6aa5582ae854c858059089ce638194a861d92b72;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1%2Foperations&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/operations&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/possible-features.mdwn;h=78a47438fe2c9d00a0ab47f99c0b64c7a801eb0f;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management%2Ftickets%2F1%2Fpossible-features&quot; rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/possible-features&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/ui.mdwn;h=debe4c625183ab3fce85cb2aa7b371e08fb2d29e;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1%2Fui&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/ui&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/views.mdwn;h=4c3f149808ad74fba579947f393b4f6a21e62bab;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management%2Ftickets%2F1%2Fviews&quot; rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/views&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/tui.mdwn;h=707ea3237ed79a556340a96e60094beb969f0403;hp=ed4986fab9a9c1d0a320e0aebbd548e2046f94a8;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftui&quot; rel=&quot;nofollow&quot;&gt;projects/tui&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;06:51:46 AM 07/29/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=696ceb85012bff250079824aa5ccf4b526031427&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+task-management: more plans&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/task-management/tickets/1 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-28T12:58:05Z</updated>
+	<published>2015-07-28T12:58:05Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1.mdwn;h=1e660face13843a722026d94ec4c2f51b2160069;hp=30461446304a9c48ebbcdf9004b5e046abf60f39;hb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e;hpb=16c22f6a025e24ca916e8312b3b5fe9146858523&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management%2Ftickets%2F1&quot; rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:58:05 PM 07/28/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+minor edit&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects projects/tui on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_16c22f6a025e24ca916e8312b3b5fe9146858523/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-16c22f6a025e24ca916e8312b3b5fe9146858523"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-28T12:56:11Z</updated>
+	<published>2015-07-28T12:56:11Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-16c22f6a025e24ca916e8312b3b5fe9146858523&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=8a382bc0b1a8668b14aad89aa4bc16711a1ed84a;hp=ec5984beb457557cddbd8d1ea7df80db9d42a705;hb=16c22f6a025e24ca916e8312b3b5fe9146858523;hpb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/tui.mdwn;h=ed4986fab9a9c1d0a320e0aebbd548e2046f94a8;hp=0000000000000000000000000000000000000000;hb=16c22f6a025e24ca916e8312b3b5fe9146858523;hpb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftui&quot; rel=&quot;nofollow&quot;&gt;projects/tui&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:56:11 PM 07/28/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=16c22f6a025e24ca916e8312b3b5fe9146858523&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+tui: research project&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/10 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-27T22:30:00Z</updated>
+	<published>2015-07-27T22:30:00Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=2dfa6c5aa076d72de618c647a17774e23cacf78f;hp=7db97bbee99f558e4dc6164e60ef81504d4afe24;hb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c;hpb=3d15ff1b8068e97901410a3d210227036bf528c5&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F10&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/10&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:30:00 PM 07/27/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update status of hello replies&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/15 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_3d15ff1b8068e97901410a3d210227036bf528c5/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-3d15ff1b8068e97901410a3d210227036bf528c5"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-27T21:43:34Z</updated>
+	<published>2015-07-27T21:43:34Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-3d15ff1b8068e97901410a3d210227036bf528c5&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=9fde6e22407a2eff47b1a666b3d3c274e5e19859;hp=8409ef6dc3f7697857b7aacdfc1d0d03ebd8e97b;hb=3d15ff1b8068e97901410a3d210227036bf528c5;hpb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:43:34 PM 07/27/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=3d15ff1b8068e97901410a3d210227036bf528c5&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update status of settings system&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide projects/funbot/manual on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_2af6df1680072d6e73f4bdb07fae2c88a59c76aa/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-2af6df1680072d6e73f4bdb07fae2c88a59c76aa"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-27T21:33:18Z</updated>
+	<published>2015-07-27T21:33:18Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-2af6df1680072d6e73f4bdb07fae2c88a59c76aa&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=6234c5babf562a6e0554c81171beb169c721b6de;hp=9d46ed7be13811c424111b5f29dc6ef641e5754a;hb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa;hpb=617249a360c6973ce7f42ad010f1276c552fbaf1&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=4fb784a3bbd9efa372438f998917e996c95946d6;hp=f179ef3cc7731f76ad0bae8b31a4e64a3f8d6871;hb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa;hpb=617249a360c6973ce7f42ad010f1276c552fbaf1&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:33:18 PM 07/27/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2af6df1680072d6e73f4bdb07fae2c88a59c76aa&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: update docs to match the newly added settings system&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects projects/funbot/tickets/15 projects/settings projects/settings/decisions projects/settings/forum projects/settings/news projects/settings/releases projects/settings/tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_617249a360c6973ce7f42ad010f1276c552fbaf1/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-617249a360c6973ce7f42ad010f1276c552fbaf1"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-22T09:46:41Z</updated>
+	<published>2015-07-22T09:46:41Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-617249a360c6973ce7f42ad010f1276c552fbaf1&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=ec5984beb457557cddbd8d1ea7df80db9d42a705;hp=9d82d759e2e847c0b174cf1bbe7f57d75c14474f;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects&quot; rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=8409ef6dc3f7697857b7aacdfc1d0d03ebd8e97b;hp=a19cd36f2568480158c63ddec2185754cab96f30;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F15&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings.mdwn;h=b7f5ffc7ee35f85a7a7d5094fdc02c578122825e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings&quot; rel=&quot;nofollow&quot;&gt;projects/settings&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/decisions.mdwn;h=7fa56d100854163543f12f83cc1408ae417f9f7e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Fdecisions&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/settings/decisions&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/forum.mdwn;h=c3b79bd4409643fdbc11a700b29898f904b315b7;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Fforum&quot; rel=&quot;nofollow&quot;&gt;projects/settings/forum&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/news.mdwn;h=837c8697a653db420eada75ea57630492eb8338e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Fnews&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/settings/news&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/releases.mdwn;h=e4efd9b315242da6e04f9e94546ed3522bdaac68;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Freleases&quot; rel=&quot;nofollow&quot;&gt;projects/settings/releases&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets.mdwn;h=e9398e875cda45921bd91361adb0716986869a15;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/settings/tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:46:41 AM 07/22/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=617249a360c6973ce7f42ad010f1276c552fbaf1&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+settings: *another* new project...&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/15 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_5f4444298ebe3f674b73a843dfc7bbef7a1703e7/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-5f4444298ebe3f674b73a843dfc7bbef7a1703e7"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-21T10:47:23Z</updated>
+	<published>2015-07-21T10:47:23Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a19cd36f2568480158c63ddec2185754cab96f30;hp=038b445accf173eee423a1a03eab722fe86ef030;hb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7;hpb=76a709cf4777cf20cf18b62c3e557f380b98a145&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F15&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:47:23 AM 07/21/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: notes about settings system&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/15 projects/funbot/tickets/4 projects/irc-fun-client/tickets/2 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_76a709cf4777cf20cf18b62c3e557f380b98a145/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-76a709cf4777cf20cf18b62c3e557f380b98a145"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-20T12:22:27Z</updated>
+	<published>2015-07-20T12:22:27Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-76a709cf4777cf20cf18b62c3e557f380b98a145&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=038b445accf173eee423a1a03eab722fe86ef030;hp=0000000000000000000000000000000000000000;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/4.mdwn;h=071cb7e64ae57c211834ee5cc7e80132209a6bc2;hp=7665ef7035b4387f9ceb84ca9cd79130b81d4d48;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F4&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/4&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-client/tickets/2.mdwn;h=ae578674d3cceaaa6cbe726d632bc3c4e87bfd55;hp=0000000000000000000000000000000000000000;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-client%2Ftickets%2F2&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-client/tickets/2&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:22:27 PM 07/20/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=76a709cf4777cf20cf18b62c3e557f380b98a145&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: more tickets...&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-messages/tickets/2 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_f65b75264b89071970cf00ff16776aa9d5969437/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-f65b75264b89071970cf00ff16776aa9d5969437"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-20T09:12:23Z</updated>
+	<published>2015-07-20T09:12:23Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-f65b75264b89071970cf00ff16776aa9d5969437&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/2.mdwn;h=e4e35c75ededb220d4ee788abd52f17ab0510352;hp=b97c3b915afa5aee1527549c97939c20979e11ba;hb=f65b75264b89071970cf00ff16776aa9d5969437;hpb=b0d2b4a707f9b0bbe5373a5ad960487b66142b41&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-messages%2Ftickets%2F2&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/2&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:12:23 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=f65b75264b89071970cf00ff16776aa9d5969437&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-messages: rearrangemet done&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/my-open-tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_b0d2b4a707f9b0bbe5373a5ad960487b66142b41/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-b0d2b4a707f9b0bbe5373a5ad960487b66142b41"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-20T09:09:43Z</updated>
+	<published>2015-07-20T09:09:43Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-b0d2b4a707f9b0bbe5373a5ad960487b66142b41&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/my-open-tickets.mdwn;h=d5fc4b5cd9696f21ab75842518f2b7a4f5fd2ebc;hp=6508a11cf60dd90ba71b998848e829d385c495d2;hb=b0d2b4a707f9b0bbe5373a5ad960487b66142b41;hpb=7bc4f88b58f7f0deadb8a79a9823a564cf399b03&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fmy-open-tickets&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/my-open-tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:09:43 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=b0d2b4a707f9b0bbe5373a5ad960487b66142b41&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+fix template typo&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to people/fr33domlover on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_7bc4f88b58f7f0deadb8a79a9823a564cf399b03/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-7bc4f88b58f7f0deadb8a79a9823a564cf399b03"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-20T09:06:01Z</updated>
+	<published>2015-07-20T09:06:01Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-7bc4f88b58f7f0deadb8a79a9823a564cf399b03&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=2230d818ac803844191d7842bcb24fa4d5e45e14;hp=f28b90121dbd2ea1427b476ec65ac299d5a362a7;hb=7bc4f88b58f7f0deadb8a79a9823a564cf399b03;hpb=e970fbaa161547af8a7b378220a602c00c128b20&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;people/fr33domlover&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:06:01 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=7bc4f88b58f7f0deadb8a79a9823a564cf399b03&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+me: use the new template for personal tickets&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/my-open-tickets templates/ticket tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_e970fbaa161547af8a7b378220a602c00c128b20/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-e970fbaa161547af8a7b378220a602c00c128b20"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-20T09:02:35Z</updated>
+	<published>2015-07-20T09:02:35Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-e970fbaa161547af8a7b378220a602c00c128b20&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/my-open-tickets.mdwn;h=6508a11cf60dd90ba71b998848e829d385c495d2;hp=0000000000000000000000000000000000000000;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fmy-open-tickets&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/my-open-tickets&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket.mdwn;h=69a8e86734dca4aec465f6d7fc4f7d6b958e9a51;hp=7adaf50d169a1a3e068b272427c5ccd010b304ea;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/ticket&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=tickets.mdwn;h=3b3e0f3959d65e0100c507940f20921dbad4220a;hp=b28306347b2b49e222ec75f0610cfceff8ff7598;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=tickets&quot; rel=&quot;nofollow&quot;&gt;tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:02:35 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=e970fbaa161547af8a7b378220a602c00c128b20&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+new template my-open-tickets&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_f650bd6d11c9f12fa342e32a1112e0326f5983a0/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-f650bd6d11c9f12fa342e32a1112e0326f5983a0"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-20T07:58:09Z</updated>
+	<published>2015-07-20T07:58:09Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=tickets.mdwn;h=b28306347b2b49e222ec75f0610cfceff8ff7598;hp=bfc33e243c877bdc29e26067fcccf60865b950f8;hb=f650bd6d11c9f12fa342e32a1112e0326f5983a0;hpb=62e6b115766812a8b7dc1661af21071b300ecf9d&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=tickets&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:58:09 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=f650bd6d11c9f12fa342e32a1112e0326f5983a0&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+tickets: add some notes and hints&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/2 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_62e6b115766812a8b7dc1661af21071b300ecf9d/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-62e6b115766812a8b7dc1661af21071b300ecf9d"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-20T07:26:24Z</updated>
+	<published>2015-07-20T07:26:24Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-62e6b115766812a8b7dc1661af21071b300ecf9d&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=2db571641ae6d30d6d74d401e2e96015b833b811;hp=ddf42fa6367bcebe483831befd8a9739a418eb69;hb=62e6b115766812a8b7dc1661af21071b300ecf9d;hpb=d1a178ecde1695f74f21132068fa479443fd364f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F2&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:26:24 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=62e6b115766812a8b7dc1661af21071b300ecf9d&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: list options for persistence&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/2 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_d1a178ecde1695f74f21132068fa479443fd364f/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-d1a178ecde1695f74f21132068fa479443fd364f"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T21:12:25Z</updated>
+	<published>2015-07-19T21:12:25Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-d1a178ecde1695f74f21132068fa479443fd364f&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=ddf42fa6367bcebe483831befd8a9739a418eb69;hp=767aaad5c981d66c8cc3f76b8ffd0b8a172c5840;hb=d1a178ecde1695f74f21132068fa479443fd364f;hpb=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F2&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:12:25 PM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=d1a178ecde1695f74f21132068fa479443fd364f&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: notes on persistent state&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to people/fr33domlover/blog/insanity on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T20:28:42Z</updated>
+	<published>2015-07-19T20:28:42Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/insanity.mdwn;h=ebaa53ca277a0e595b242642aeed217a2d596b54;hp=0000000000000000000000000000000000000000;hb=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a;hpb=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fblog%2Finsanity&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;people/fr33domlover/blog/insanity&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;08:28:42 PM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+me: some blog post...&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/ticket-depends-on on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_6f2e5495944f200e1e6dd231d85ecbdfbb1aa372/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-6f2e5495944f200e1e6dd231d85ecbdfbb1aa372"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T09:26:58Z</updated>
+	<published>2015-07-19T09:26:58Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-6f2e5495944f200e1e6dd231d85ecbdfbb1aa372&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hp=a7f05948f92be66460fa39f2d7ac61c863886994;hb=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372;hpb=b3db4bb425ef79edc4269c0ad57e47685eb888b7&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:26:58 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+if failing, at least fail explicitly&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/ticket-depends-on on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_b3db4bb425ef79edc4269c0ad57e47685eb888b7/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-b3db4bb425ef79edc4269c0ad57e47685eb888b7"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T09:15:03Z</updated>
+	<published>2015-07-19T09:15:03Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-b3db4bb425ef79edc4269c0ad57e47685eb888b7&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=a7f05948f92be66460fa39f2d7ac61c863886994;hp=0279afa3d1b2bb1796ba9e32955894c6e8436c5e;hb=b3db4bb425ef79edc4269c0ad57e47685eb888b7;hpb=5b2a8e163184284378d48d2419134d6f5e4fabbe&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fticket-depends-on&quot; rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:15:03 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=b3db4bb425ef79edc4269c0ad57e47685eb888b7&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+last try, I have no idea about those variables&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/ticket-depends-on on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_5b2a8e163184284378d48d2419134d6f5e4fabbe/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-5b2a8e163184284378d48d2419134d6f5e4fabbe"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T09:00:55Z</updated>
+	<published>2015-07-19T09:00:55Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-5b2a8e163184284378d48d2419134d6f5e4fabbe&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=0279afa3d1b2bb1796ba9e32955894c6e8436c5e;hp=6e5d9e5744a8b7f07502689526a0bb398df695a6;hb=5b2a8e163184284378d48d2419134d6f5e4fabbe;hpb=476809c178ec0873f4580309443add856c64f339&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;09:00:55 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5b2a8e163184284378d48d2419134d6f5e4fabbe&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+try again&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/ticket-depends-on on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_476809c178ec0873f4580309443add856c64f339/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-476809c178ec0873f4580309443add856c64f339"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T08:43:09Z</updated>
+	<published>2015-07-19T08:43:09Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-476809c178ec0873f4580309443add856c64f339&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=6e5d9e5744a8b7f07502689526a0bb398df695a6;hp=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hb=476809c178ec0873f4580309443add856c64f339;hpb=42242ce1aeb36d653d3312ee46603ca1baeb5f78&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;08:43:09 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=476809c178ec0873f4580309443add856c64f339&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+try to fix local ticket dependency template&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/5 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_42242ce1aeb36d653d3312ee46603ca1baeb5f78/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-42242ce1aeb36d653d3312ee46603ca1baeb5f78"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T00:52:24Z</updated>
+	<published>2015-07-19T00:52:24Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-42242ce1aeb36d653d3312ee46603ca1baeb5f78&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=b9debec3ded1ba8f5151f21acfc3ce6f340f9d06;hp=0e5a1030b7c2ef5dbd1c505352d9172e94bf04d3;hb=42242ce1aeb36d653d3312ee46603ca1baeb5f78;hpb=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F5&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:52:24 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=42242ce1aeb36d653d3312ee46603ca1baeb5f78&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+fix typo&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/5 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_bd0e46e488bbeb8b216f6ab1aefd98083ec61f16/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-bd0e46e488bbeb8b216f6ab1aefd98083ec61f16"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-19T00:48:08Z</updated>
+	<published>2015-07-19T00:48:08Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-bd0e46e488bbeb8b216f6ab1aefd98083ec61f16&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=0e5a1030b7c2ef5dbd1c505352d9172e94bf04d3;hp=fac452baf181d140dfd541dd3e348b03f4387a1a;hb=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16;hpb=e048d2ba90a4e6f94784c809618051f00a863627&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F5&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:48:08 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-bot: close ticket 5, user tracking works&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/tktref on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_e048d2ba90a4e6f94784c809618051f00a863627/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-e048d2ba90a4e6f94784c809618051f00a863627"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-18T16:18:02Z</updated>
+	<published>2015-07-18T16:18:02Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-e048d2ba90a4e6f94784c809618051f00a863627&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/tktref.mdwn;h=a0c97a7571758f0b9ecbdd87da123ddc23e3add3;hp=fc64ea4a97b82588f1cb5c72d9875cbedc196f6b;hb=e048d2ba90a4e6f94784c809618051f00a863627;hpb=64fc69565cd08b8438d34b6453840eec6c328677&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Ftktref&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/tktref&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;04:18:02 PM 07/18/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=e048d2ba90a4e6f94784c809618051f00a863627&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+try to fix tktlink rendering&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/5 projects/irc-fun-messages/tickets/1 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_64fc69565cd08b8438d34b6453840eec6c328677/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-64fc69565cd08b8438d34b6453840eec6c328677"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-18T16:13:16Z</updated>
+	<published>2015-07-18T16:13:16Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-64fc69565cd08b8438d34b6453840eec6c328677&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=fac452baf181d140dfd541dd3e348b03f4387a1a;hp=c3fda7dceeea8bd5b28f491e969db289e813a59a;hb=64fc69565cd08b8438d34b6453840eec6c328677;hpb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/1.mdwn;h=b591bb5228526e4e0c28619d1d51642bd35db0ca;hp=9ef221af24707831f812d2a735fcfa1ed60c2188;hb=64fc69565cd08b8438d34b6453840eec6c328677;hpb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages%2Ftickets%2F1&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/1&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;04:13:16 PM 07/18/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=64fc69565cd08b8438d34b6453840eec6c328677&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-*: reply analysis added, now track nicknames&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects projects/irc-fun-color projects/irc-fun-color/decisions projects/irc-fun-color/forum projects/irc-fun-color/news projects/irc-fun-color/releases projects/irc-fun-color/tickets on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-18T15:08:45Z</updated>
+	<published>2015-07-18T15:08:45Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=9d82d759e2e847c0b174cf1bbe7f57d75c14474f;hp=2f60c659996eb1080d7af967e9041d62d77d84c9;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color.mdwn;h=55a94ef29608a2cf99061cfff38117975ad31fa3;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-color&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-color&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/decisions.mdwn;h=86674bf28a1eac5aa6a8f6bf02a5f3611fae5afe;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Fdecisions&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/decisions&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/forum.mdwn;h=f297d56c4a7e9099c511dafd8deeec28222e3e17;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-color%2Fforum&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/forum&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/news.mdwn;h=330c55f6fd7f2c4a010044249adcb5456d9658a3;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Fnews&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/news&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/releases.mdwn;h=57e5729d6313d999900ce903adcc35389f4686bb;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Freleases&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/releases&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/tickets.mdwn;h=707729b4f5edb530c7493f701639e14441ece6fb;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-color%2Ftickets&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/tickets&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;03:08:45 PM 07/18/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-color: new project&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/ticket-depends-on on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_3d1ea877911070c0d95bb46c10568bde7b956ae6/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-3d1ea877911070c0d95bb46c10568bde7b956ae6"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-17T12:13:32Z</updated>
+	<published>2015-07-17T12:13:32Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hp=36db3bfac2156cf7980068af0606bf464cd5b6ec;hb=3d1ea877911070c0d95bb46c10568bde7b956ae6;hpb=5361eae41a1dbd74b511f97df16687a0278063d6&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:13:32 PM 07/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+template: try to make ticket-depends-on render as a single line&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/tktref on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_5361eae41a1dbd74b511f97df16687a0278063d6/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-5361eae41a1dbd74b511f97df16687a0278063d6"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-17T12:07:39Z</updated>
+	<published>2015-07-17T12:07:39Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-5361eae41a1dbd74b511f97df16687a0278063d6&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/tktref.mdwn;h=fc64ea4a97b82588f1cb5c72d9875cbedc196f6b;hp=cc3d879c0f434325cf3e0a35768810a4d4c40cb3;hb=5361eae41a1dbd74b511f97df16687a0278063d6;hpb=8acf634f485a70e7f54faa48d5ceaff705849359&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Ftktref&quot; rel=&quot;nofollow&quot;&gt;templates/tktref&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:07:39 PM 07/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5361eae41a1dbd74b511f97df16687a0278063d6&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+templates: fix typo in tktref&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/ticket-dependants templates/ticket on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_8acf634f485a70e7f54faa48d5ceaff705849359/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-8acf634f485a70e7f54faa48d5ceaff705849359"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-17T11:59:11Z</updated>
+	<published>2015-07-17T11:59:11Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-8acf634f485a70e7f54faa48d5ceaff705849359&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-dependants.mdwn;h=8996711ad0b53f3acc95eb2fb577260f56f99589;hp=0000000000000000000000000000000000000000;hb=8acf634f485a70e7f54faa48d5ceaff705849359;hpb=4826e57427eb5fdc542b22534276401ef0e0a6bb&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fticket-dependants&quot; rel=&quot;nofollow&quot;&gt;templates/ticket-dependants&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket.mdwn;h=7adaf50d169a1a3e068b272427c5ccd010b304ea;hp=cc70c7b4bcf5718cf457b8bc8f9760c3c2dec296;hb=8acf634f485a70e7f54faa48d5ceaff705849359;hpb=4826e57427eb5fdc542b22534276401ef0e0a6bb&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/ticket&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:59:11 AM 07/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=8acf634f485a70e7f54faa48d5ceaff705849359&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+add ticket reverse dependencies using tags&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/10 projects/funbot/tickets/3 projects/funbot/tickets/5 projects/idan/tickets/4 projects/irc-fun-bot/tickets/5 projects/sif/tickets/Remove_doxy_references_to_nonfree_browsers projects/sif/tickets/Remove_unused_doxy_images templates/ticket-depends-on on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_4826e57427eb5fdc542b22534276401ef0e0a6bb/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-4826e57427eb5fdc542b22534276401ef0e0a6bb"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-17T11:27:55Z</updated>
+	<published>2015-07-17T11:27:55Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-4826e57427eb5fdc542b22534276401ef0e0a6bb&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=7db97bbee99f558e4dc6164e60ef81504d4afe24;hp=f679a8578818b1b59ef502b4e83d972a2696ba2a;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F10&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/10&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/3.mdwn;h=111efa1b015906623afc28c27ee52742a7cddbd8;hp=09da3b9886f12272ba40bde42dcb4ebbd0846de9;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F3&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/3&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=606f28657913248cbfe3204aa6f0ffebec656b55;hp=f605f0ecc0227205dad3b5d4b16c4fdb85df5eb5;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F5&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/5&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/idan/tickets/4.mdwn;h=a4e6bd9fb63289481b2ebea90b374aa0236a604a;hp=e4f1d49482e7e2c66e404a9a0efcdc0bfb29950d;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fidan%2Ftickets%2F4&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/idan/tickets/4&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=c3fda7dceeea8bd5b28f491e969db289e813a59a;hp=215a25f288dfeb80ea06314a6c1b860a1476622e;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/sif/tickets/Remove_doxy_references_to_nonfree_browsers.mdwn;h=944fb3a116e57ee64af34d891fa43327468b0228;hp=5b6919b3d065d46f997e6abb1f63130978a5e9af;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsif%2Ftickets%2FRemove_doxy_references_to_nonfree_browsers&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/sif/tickets/Remove doxy references to nonfree browsers&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/sif/tickets/Remove_unused_doxy_images.mdwn;h=7f4205dd1dd777bbbf86e08147e73c427c66d984;hp=c54d10be8cc161461d2d1b535b29043cdbdb9fb6;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsif%2Ftickets%2FRemove_unused_doxy_images&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/sif/tickets/Remove unused doxy images&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=36db3bfac2156cf7980068af0606bf464cd5b6ec;hp=55583bce2cd010f8cf8b3271621428169d3b57a2;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:27:55 AM 07/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=4826e57427eb5fdc542b22534276401ef0e0a6bb&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+templates: hopefully improve ticket-depends-on&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/5 projects/irc-fun-messages/tickets/1 projects/irc-fun-messages/tickets/2 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_2a4c41ea9590cd73e0aec952e93f745172a32217/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-2a4c41ea9590cd73e0aec952e93f745172a32217"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-17T10:45:46Z</updated>
+	<published>2015-07-17T10:45:46Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-2a4c41ea9590cd73e0aec952e93f745172a32217&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=215a25f288dfeb80ea06314a6c1b860a1476622e;hp=9c3b99793d6df15691e519bd472b674b37b871a6;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/1.mdwn;h=9ef221af24707831f812d2a735fcfa1ed60c2188;hp=0000000000000000000000000000000000000000;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-messages%2Ftickets%2F1&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/1&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/2.mdwn;h=b97c3b915afa5aee1527549c97939c20979e11ba;hp=0000000000000000000000000000000000000000;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages%2Ftickets%2F2&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/2&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;10:45:46 AM 07/17/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=2a4c41ea9590cd73e0aec952e93f745172a32217&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-messages: open tickets for work being done&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/14 projects/irc-fun-bot/tickets/6 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_8fb78e1a159821745b973337a7267635a536f3fc/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-8fb78e1a159821745b973337a7267635a536f3fc"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-16T12:50:22Z</updated>
+	<published>2015-07-16T12:50:22Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-8fb78e1a159821745b973337a7267635a536f3fc&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/14.mdwn;h=ec589115c87f1e070cf74a0e74bd88fa16320fd5;hp=0000000000000000000000000000000000000000;hb=8fb78e1a159821745b973337a7267635a536f3fc;hpb=18355348f643f521d5172530761ce01abe472ed9&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F14&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/14&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/6.mdwn;h=dc30d1b5dbb1e84f25aebe68f2a00c626870469b;hp=0000000000000000000000000000000000000000;hb=8fb78e1a159821745b973337a7267635a536f3fc;hpb=18355348f643f521d5172530761ce01abe472ed9&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F6&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/6&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:50:22 PM 07/16/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=8fb78e1a159821745b973337a7267635a536f3fc&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: tickets for Tox and OTR support&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/5 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_18355348f643f521d5172530761ce01abe472ed9/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-18355348f643f521d5172530761ce01abe472ed9"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-15T12:43:41Z</updated>
+	<published>2015-07-15T12:43:41Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-18355348f643f521d5172530761ce01abe472ed9&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=9c3b99793d6df15691e519bd472b674b37b871a6;hp=17f55a86e0f23d45f9b2edb4f6daec60c2dc0d82;hb=18355348f643f521d5172530761ce01abe472ed9;hpb=143590cacdab92492eb6a14e53c9810f4432cd4b&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:43:41 PM 07/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=18355348f643f521d5172530761ce01abe472ed9&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-bot: notes on online user tracking&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/4 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_143590cacdab92492eb6a14e53c9810f4432cd4b/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-143590cacdab92492eb6a14e53c9810f4432cd4b"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-15T12:28:53Z</updated>
+	<published>2015-07-15T12:28:53Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-143590cacdab92492eb6a14e53c9810f4432cd4b&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=de50db2d43720e278918b08a15a70fb01065310c;hp=861efebe845edc70875723113005c9292a8181a6;hb=143590cacdab92492eb6a14e53c9810f4432cd4b;hpb=1d7deccdc53477739f5f644a14ddfc08276eb330&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F4&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/4&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:28:53 PM 07/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=143590cacdab92492eb6a14e53c9810f4432cd4b&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-bot: close ticket 4, event handling implemented&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/commit templates/record on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_1d7deccdc53477739f5f644a14ddfc08276eb330/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-1d7deccdc53477739f5f644a14ddfc08276eb330"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-15T12:28:19Z</updated>
+	<published>2015-07-15T12:28:19Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-1d7deccdc53477739f5f644a14ddfc08276eb330&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/commit.mdwn;h=2216a0ee714109c1860d714832f0a8e1935bdc0a;hp=e715dab0360f63da76233aa8d6018cb5511dd183;hb=1d7deccdc53477739f5f644a14ddfc08276eb330;hpb=74e38e99ab317f66273387b40a96f3817a9a269f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fcommit&quot; rel=&quot;nofollow&quot;&gt;templates/commit&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/record.mdwn;h=b6d048ab252338b6994ea0ee8b04b73db7a4a778;hp=cf2916d42321a35e788ca8121243e4e3e9a1ca3c;hb=1d7deccdc53477739f5f644a14ddfc08276eb330;hpb=74e38e99ab317f66273387b40a96f3817a9a269f&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Frecord&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/record&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:28:19 PM 07/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1d7deccdc53477739f5f644a14ddfc08276eb330&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+templates: update record template link text&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to templates/commit templates/record on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_74e38e99ab317f66273387b40a96f3817a9a269f/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-74e38e99ab317f66273387b40a96f3817a9a269f"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-15T11:38:43Z</updated>
+	<published>2015-07-15T11:38:43Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-74e38e99ab317f66273387b40a96f3817a9a269f&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/commit.mdwn;h=e715dab0360f63da76233aa8d6018cb5511dd183;hp=0000000000000000000000000000000000000000;hb=74e38e99ab317f66273387b40a96f3817a9a269f;hpb=54fd05dc71003ad59211bf218528dd21f1386759&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fcommit&quot; rel=&quot;nofollow&quot;&gt;templates/commit&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/record.mdwn;h=cf2916d42321a35e788ca8121243e4e3e9a1ca3c;hp=0000000000000000000000000000000000000000;hb=74e38e99ab317f66273387b40a96f3817a9a269f;hpb=54fd05dc71003ad59211bf218528dd21f1386759&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Frecord&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;templates/record&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:38:43 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=74e38e99ab317f66273387b40a96f3817a9a269f&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+templates: add git/darcs record templates&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/guide on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_54fd05dc71003ad59211bf218528dd21f1386759/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-54fd05dc71003ad59211bf218528dd21f1386759"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-15T11:38:19Z</updated>
+	<published>2015-07-15T11:38:19Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-54fd05dc71003ad59211bf218528dd21f1386759&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=9d46ed7be13811c424111b5f29dc6ef641e5754a;hp=ac4c2f5842f1194f7e20148f70c265952cb990f9;hb=54fd05dc71003ad59211bf218528dd21f1386759;hpb=07d23f596ab3b6281acdd9f80768ab64b014bd49&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:38:19 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=54fd05dc71003ad59211bf218528dd21f1386759&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: add list of API features to the guide&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/4 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_07d23f596ab3b6281acdd9f80768ab64b014bd49/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-07d23f596ab3b6281acdd9f80768ab64b014bd49"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-15T00:24:59Z</updated>
+	<published>2015-07-15T00:24:59Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-07d23f596ab3b6281acdd9f80768ab64b014bd49&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=861efebe845edc70875723113005c9292a8181a6;hp=4cda87eb8f895f7dee560b8df646d1c7d5e4601a;hb=07d23f596ab3b6281acdd9f80768ab64b014bd49;hpb=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F4&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/4&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:24:59 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=07d23f596ab3b6281acdd9f80768ab64b014bd49&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-bot: more notes on ticket 4: events types&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/13 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-15T00:04:20Z</updated>
+	<published>2015-07-15T00:04:20Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/13.mdwn;h=b6905577f100cfddf71d2589136637129d7016a1;hp=0000000000000000000000000000000000000000;hb=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a;hpb=efaad54e5facfab7d5048a058407a733b987f877&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F13&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/13&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;12:04:20 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: new ticket: collecting quotes&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/irc-fun-bot/tickets/4 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_efaad54e5facfab7d5048a058407a733b987f877/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-efaad54e5facfab7d5048a058407a733b987f877"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-14T23:48:18Z</updated>
+	<published>2015-07-14T23:48:18Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-efaad54e5facfab7d5048a058407a733b987f877&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=4cda87eb8f895f7dee560b8df646d1c7d5e4601a;hp=d3eb459357a0fe4b6922f45adfaabf25f6753d68;hb=efaad54e5facfab7d5048a058407a733b987f877;hpb=ca1c11f89649f6d8e2ee1e875edf2c4232447c92&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F4&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/4&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;11:48:18 PM 07/14/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=efaad54e5facfab7d5048a058407a733b987f877&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+irc-fun-bot: thoughts on ticket 4&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to people/fr33domlover on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_ca1c11f89649f6d8e2ee1e875edf2c4232447c92/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-ca1c11f89649f6d8e2ee1e875edf2c4232447c92"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-13T19:56:20Z</updated>
+	<published>2015-07-13T19:56:20Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-ca1c11f89649f6d8e2ee1e875edf2c4232447c92&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=f28b90121dbd2ea1427b476ec65ac299d5a362a7;hp=6f209d9fe79aaea43836b9e010f6879ef7428cbc;hb=ca1c11f89649f6d8e2ee1e875edf2c4232447c92;hpb=6d3a6ade9202b71c87723db5d8d99f95625995d0&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;people/fr33domlover&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;07:56:20 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=ca1c11f89649f6d8e2ee1e875edf2c4232447c92&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+me: not anymore&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/manual projects/funbot/tickets/9 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_6d3a6ade9202b71c87723db5d8d99f95625995d0/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-6d3a6ade9202b71c87723db5d8d99f95625995d0"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-13T16:31:31Z</updated>
+	<published>2015-07-13T16:31:31Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-6d3a6ade9202b71c87723db5d8d99f95625995d0&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=f179ef3cc7731f76ad0bae8b31a4e64a3f8d6871;hp=c664554baaa6d752bb6412372ae3e03c25f88691;hb=6d3a6ade9202b71c87723db5d8d99f95625995d0;hpb=75eade8953e45278446e742d970840fd5686a759&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fmanual&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9.mdwn;h=f3728f733ee4e81e0cf9e6aa40df787378449c85;hp=1dcfa08f772cc596392b61eaed26d494b37f4e17;hb=6d3a6ade9202b71c87723db5d8d99f95625995d0;hpb=75eade8953e45278446e742d970840fd5686a759&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F9&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/9&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;04:31:31 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=6d3a6ade9202b71c87723db5d8d99f95625995d0&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+funbot: finish manual and close ticket 9, Jookia&amp;#39;s patch applied - thanks!&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/9 on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_75eade8953e45278446e742d970840fd5686a759/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-75eade8953e45278446e742d970840fd5686a759"/>
+
+	<author><name>jookia</name></author>
+
+
+
+
+
+	<updated>2015-07-13T15:29:57Z</updated>
+	<published>2015-07-13T15:29:57Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-75eade8953e45278446e742d970840fd5686a759&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9.mdwn;h=1dcfa08f772cc596392b61eaed26d494b37f4e17;hp=b5300d432f0b164e9ddd5cf70630ec04caca47c6;hb=75eade8953e45278446e742d970840fd5686a759;hpb=660f57dbd862851e014100f04657b9b9f20bd8dd&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F9&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/9&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Fjookia&quot; rel=&quot;nofollow&quot;&gt;jookia&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;web&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;03:29:57 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=75eade8953e45278446e742d970840fd5686a759&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/funbot/tickets/9/0001-info-Add-copying-information.patch on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_660f57dbd862851e014100f04657b9b9f20bd8dd/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-660f57dbd862851e014100f04657b9b9f20bd8dd"/>
+
+	<author><name>jookia</name></author>
+
+
+
+
+
+	<updated>2015-07-13T15:25:55Z</updated>
+	<published>2015-07-13T15:25:55Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-660f57dbd862851e014100f04657b9b9f20bd8dd&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9/0001-info-Add-copying-information.patch;h=1c6b87a3543f57c62bc123bc441be563c0a18a75;hp=0000000000000000000000000000000000000000;hb=660f57dbd862851e014100f04657b9b9f20bd8dd;hpb=69a4b71b5f5359915ae8a9c17cd12778e577267b&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F9%2F0001-info-Add-copying-information.patch&quot; rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/9/0001-info-Add-copying-information.patch&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=people%2Fjookia&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;jookia&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;web&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;03:25:55 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?rev=660f57dbd862851e014100f04657b9b9f20bd8dd&amp;amp;do=revert&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+attachment upload&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+<entry>
+	<title>change to projects/libravatar projects/libravatar/tickets/1 projects/libravatar/tickets/Please_provide_sample_code on Rel4tion</title>
+
+	<id>http://www.rel4tion.org/recentchanges/change_69a4b71b5f5359915ae8a9c17cd12778e577267b/</id>
+
+	<link href="http://www.rel4tion.org/recentchanges/#change-69a4b71b5f5359915ae8a9c17cd12778e577267b"/>
+
+	<author><name>fr33domlover</name></author>
+
+
+
+
+
+	<updated>2015-07-13T14:57:10Z</updated>
+	<published>2015-07-13T14:57:10Z</published>
+
+
+	<content type="html" xml:lang="en">
+	
+
+
+
+
+
+
+
+&lt;div id=&quot;change-69a4b71b5f5359915ae8a9c17cd12778e577267b&quot; class=&quot;metadata&quot;&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
+&lt;span class=&quot;pagelinks&quot;&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar.mdwn;h=da1600f753365123dc129bbbb8d306aa48b76e04;hp=a462742b8577f6ceedb5ce392b9b5fd7a56c97af;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/libravatar&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar/tickets/1.mdwn;h=be178d41ce929dd13f79a42efdce42814cfd781c;hp=0000000000000000000000000000000000000000;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar%2Ftickets%2F1&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/libravatar/tickets/1&lt;/a&gt;
+
+
+&lt;a href=&quot;http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar/tickets/Please_provide_sample_code.mdwn;h=0000000000000000000000000000000000000000;hp=e2ef3abcf2e8dc5bb11d3a0d367fc01a4892123d;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586&quot; title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot; alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar%2Ftickets%2FPlease_provide_sample_code&amp;amp;do=goto&quot; rel=&quot;nofollow&quot;&gt;projects/libravatar/tickets/Please provide sample code&lt;/a&gt;
+
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
+&lt;span class=&quot;committer&quot;&gt;
+
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot; rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
+
+&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
+&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
+&lt;span class=&quot;changedate&quot;&gt;&lt;span class=&quot;date&quot;&gt;02:57:10 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
+&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
+&lt;span class=&quot;revert&quot;&gt;
+&lt;a href=&quot;http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=69a4b71b5f5359915ae8a9c17cd12778e577267b&quot; title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot; alt=&quot;revert&quot; /&gt;&lt;/a&gt;
+&lt;/span&gt;
+&lt;/div&gt;
+&lt;div class=&quot;changelog&quot;&gt;
+
+
+libravatar: reply on ticket 1&lt;br /&gt;
+
+
+&lt;/div&gt;
+
+
+
+	</content>
+
+
+
+</entry>
+
+</feed>
-- 
1.9.1


From yom at artyom.me  Tue Sep 29 18:42:55 2015
From: yom at artyom.me (Artyom)
Date: Tue, 29 Sep 2015 21:42:55 +0300
Subject: [Haskell-cafe] =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?=
 =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?=
Message-ID: <560ADBAF.3060006@artyom.me>

Hello!

I'd like to announce the release of Megaparsec, a fork of Parsec that has
been in the works for the past 2 months. There's a lot of improvements and
bugfixes under the hood ? as well as a new test suite with 128 Quickcheck
tests covering 80% of code (Parsec has only 3 tests, by the way) ? but first
I'd like to explain why a fork was needed, since forking a popular 
library is
a pretty drastic measure and should be accompanied by an explanation. (A
disclaimer: I've been given permission to announce the library, but I'm
neither the author nor an expert on parsing.)

     Hackage:
     https://hackage.haskell.org/package/megaparsec

     Changelog (including a list of differences from Parsec):
     https://hackage.haskell.org/package/megaparsec/changelog

     Github:
     https://github.com/mrkkrp/megaparsec

If you ever had any ideas about what Parsec should've done differently, or
what amazing new combinators it should include, etc., post your ideas here:

     https://github.com/mrkkrp/megaparsec/issues

Why fork Parsec instead of writing a new library
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are many parsing libraries on Hackage; Parsec was one of the first to
appear, and it's still the one that is recommended to beginners when 
they ask
about doing parsing in Haskell. Most other libraries aren't exactly 
trying to
compete with Parsec ? instead they explore new directions.

Like it or not, it remains a fact that a lot of people are being recommended
Parsec, a lot of people are using Parsec, and a lot of people will probably
continue to use Parsec since there's no clear alternative to it. Writing a
new and *different* library probably won't change it. Even new and *similar*
libraries (trifecta and attoparsec are similar enough) haven't removed the
need for Parsec, only mitigated it somewhat. Perhaps one day trifecta or
something else will completely replace Parsec, but right now we still 
have to
put up with Parsec. So, what we need (or at least what would be nice to 
have)
is simply a better Parsec.

What's wrong with original Parsec
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Parsec's development has stagnated long ago; you'd have a hard time getting
your pull request merged, even if the only thing it does is fixing a typo
(I'm not even talking about anything more controversial than that). Parsec
isn't perfect or bug-free, and there *is* a need for those pull requests ?
just look at its Github page, where you'll find 8 unmerged PRs (and 9 open
issues):

     https://github.com/aslatter/parsec

In addition to things that could be fixed but simply aren't, there are some
inconveniences (and bugs!) that are hard to fix without breaking backwards
compatibility:

* ?notFollowedBy eof? will just silently not do what you expect it to do (a
   bug old enough to be considered an undocumented feature)

* ?<|>? and ?many? are redefined and so importing Text.Parsec clashes with
   Control.Applicative (this can't be trivially fixed in Parsec because its
   ?<|>? has different precedence from Control.Applicative's ?<|>?)

* you can't wrap Parser into monad transformers (I'm talking about things
   like ?WriterT [String] Parser a? ? if this was possible, there'd be no
   need for ?user state? baked into ParsecT)

* ?Text.Parsec.Token? is not flexible enough for many needs; if you 
depend on
   it, one day you may find that you have to copy the whole module to 
get the
   behavior you want (look at 
https://github.com/aslatter/parsec/issues/15 and
   https://github.com/aslatter/parsec/issues/24, for example).

In short, there may be a lot of value in improving Parsec ? and that's where
Megaparsec comes in.

What is Megaparsec and how is it different
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Megaparsec ?reboots? the development of Parsec. It's not backwards
compatible, but it *is* compatible enough to avoid having to rewrite all
Parsec tutorials, and code written for Parsec can be converted to use
Megaparsec pretty mechanically. Given that, I would recommend using
Megaparsec instead of Parsec from now on, unless you need compatibility with
GHCs older than 7.10.

Here is a detailed account of some of the bigger changes:

=== Error reporting ===

Megaparsec's errors messages are significantly more accurate than 
Parsec's in
some cases, as the following demonstration shows.

Parsec:

     > parseTest (try (string "let") <|> string "lexical") "le"
     parse error at (line 1, column 1):
     unexpected end of input
     expecting "lexical"

Megaparsec:

     > parseTest (try (string "let") <|> string "lexical") "le"
     parse error at line 1, column 1:
     unexpected "le"
     expecting "let" or "lexical"

And here's another one, showing off how sometimes ?try a <|> b? is a bit
less harmful than usual. Just in case, I'm talking about this blog post:

http://blog.ezyang.com/2014/05/parsec-try-a-or-b-considered-harmful/

If you don't want to read it in full, the gist of it is that if you use 
?try?
too liberally, Parsec's error messages become much worse than they could be.
In this example, we're trying to parse a simple version of Haskell's import
statements, which can look either as ?import Foo? or ?import qualified 
Foo as
B?. If you write a parser like this:

     try pQualifiedImport <|> pImport

you will get an uninformative error message on the following input:

     import qualified Foo s B

Specifically, the ?try pQualifiedImport? branch will fail, and then the
?pImport? branch will stumble upon ?qualified? ? while the actual error
isn't there, but in misspelled ?as?.

The advice given in the blog post (?The scope of backtracking try should be
minimized?) is good, and applies to Megaparsec just as well as it applies to
Parsec. However, a curious thing is that in this particular case Parsec
*should* be able to tell you that the error is in misspelled ?as?, because
Parsec implements the longest match rule ? errors that occur later in text
are given precedence over errors that occur earlier. The code is there, but
somehow it doesn't do what it's supposed to do (and Megaparsec fixes that).

Here's the code from the article, rewritten for Megaparsec:

     import Text.Megaparsec
     import qualified Text.Megaparsec.Lexer as L

     data Stmt = QualifiedImport String String | Import String
       deriving (Show)

     pStmt = try pQualifiedImport <|> pImport

     pImport = do
       keyword "import"
       Import <$> upperCaseIdentifier

     pQualifiedImport = do
       keyword "import"
       keyword "qualified"
       QualifiedImport
         <$> upperCaseIdentifier
         <*> (keyword "as" *> upperCaseIdentifier)

     upperCaseIdentifier = lexeme $
       (:) <$> upperChar <*> many (alphaNumChar <|> oneOf "_.")

     lexeme  = L.lexeme (hidden space)
     keyword = L.symbol (hidden space)

And here are the error messages it produces. Megaparsec:

     > parseTest (pStmt >> eof) "import qualified Foo s B"
     parse error at line 1, column 22:
     unexpected 's'
     expecting "as"

Parsec (with minor modifications):

     > parseTest (pStmt >> eof) "import qualified Foo s B"
     parse error at (line 1, column 8):
     unexpected "q"
     expecting uppercase letter

=== Integration with monad transformers ===

The key type of Parsec is ?ParsecT? (others, such as ?Parsec? and ?Parser?,
are just type synonyms). It lets you use parsers with other monads ? for
instance, if you use ?ParsecT String () IO?, you can have IO in your
parsers. This is the reason, by the way, why ?char? has the type

     char :: Stream s m Char => Char -> ParsecT s u m Char

instead of a simpler

     char :: Char -> Parser Char

(If it was the latter, you wouldn't be able to use ?char? and IO in the
same parser.)

However, even this type isn't general enough for all things you might want
to do. Imagine that you want some parsers to generate warnings when they
are run, and later you want to collect those warnings and do something with
them. This sounds like what Writer was invented for, so you try to use it.
Now all your parsers have this type:

     ParsecT String () (Writer [Warning])

(Where ?Warning? is, say, a synonym for String.)

Unfortunately, this is not how you should've composed ParsecT and Writer,
because this way you don't get backtracking ? in other words, if you try
to do

     optional (try someParser)

and someParser generates warnings but then fails, ?optional? won't be able
to make them disappear ? they will still be recorded. Same with State ? if
you do

     x <* notFollowedBy y

and ?y? changes the state, this change will be recorded even tho it's not
what you want most of the time. (You can use Parsec's internal state and
it *will* work, but it doesn't help you when you want to use Writer or
something else instead of State.)

What you want in such situations is

     WriterT [Warning] Parser ()
     StateT YourState Parser ()
     ...

but you can't get it because ?char? and all other primitive parsers simply
don't have those types. With Parsec, the only solution is to apply ?lift? to
all parsers you want to use, which is pretty annoying. Megaparsec solves
this by introducing an mtl-style ?MonadParsec? class, making primitive
parsers members of this class, and providing instances of MonadParsec for
various monad transformers. (If you have ever used the ?parsers? library,
you may recognise this approach.) I think being able to get backtracking
behavior without relying on inelegant ways like ?Parsec user state? is
pretty neat, even if it's not something every Parsec user needs.

=== Lexing ===

Parsec has a lexing module (Text.Parsec.Token):

http://hackage.haskell.org/package/parsec/docs/Text-Parsec-Token.html

If you're not familiar with lexing, the idea is as follows. When you are
parsing a programming language, you often have to solve the same set of
problems ? parsing numbers, string literals (with all those escaping rules),
identifiers/operators/keywords, comments, making all parsers handle
whitespace (since there can be whitespace between pretty much any 2 tokens),
and so on. With ?Text.Parsec.Token? you could just specify what counts as
whitespace, as a comment, as an identifier character, etc. and get a set of
parsers ?for free?.

Parsec achieves this by defining a huge structure called ?GenLanguageDef?
that contains the specification of your language:

     data GenLanguageDef s u m =
       LanguageDef {
         commentStart    :: String,
         commentEnd      :: String,
         commentLine     :: String,
         nestedComments  :: Bool,
         identStart      :: ParsecT s u m Char,
         identLetter     :: ParsecT s u m Char,
         opStart         :: ParsecT s u m Char,
         opLetter        :: ParsecT s u m Char,
         reservedNames   :: [String],
         reservedOpNames :: [String],
         caseSensitive   :: Bool }

Then you use ?makeTokenParser? on it to generate another huge structure
containing lots of useful parsers:

     makeTokenParser :: GenLanguageDef ... -> GenTokenParser ...

     data GenTokenParser s u m =
       TokenParser {
         identifier    :: ParsecT s u m String,
         operator      :: ParsecT s u m String,
         charLiteral   :: ParsecT s u m Char,
         stringLiteral :: ParsecT s u m String,
         natural       :: ParsecT s u m Integer,
         integer       :: ParsecT s u m Integer,
         float         :: ParsecT s u m Double,
         lexeme        :: forall a. ParsecT s u m a -> ParsecT s u m a,
         parens        :: forall a. ParsecT s u m a -> ParsecT s u m a,
         braces        :: forall a. ParsecT s u m a -> ParsecT s u m a,
         comma         :: ParsecT s u m String,
         colon         :: ParsecT s u m String,
         ... }

What's the problem with this approach? It's very inflexible ? the moment
you want to change something that wasn't supposed to be changed, you're on
your own. Do you want to special-case ?-- |? comments to use them as doc
strings? The easiest solution is to copy the whole module into your own
project:

     https://github.com/aslatter/parsec/issues/15

Do you want to handle newlines by yourself (for instance, to allow them to
be expression separators)? The easiest solution is to fork Parsec:

     https://github.com/aslatter/parsec/issues/24

(Even if those turn out not to be the easiest solutions, it's still
somewhat telling that they were what the authors ended up with.)

Megaparsec uses a simpler, more flexible approach. See the docs here:

https://hackage.haskell.org/package/megaparsec/docs/Text-Megaparsec-Lexer.html

The linked module provides 3 categories of functions:

   * ?integer?, ?decimal?, ?float?, ?charLiteral?, etc are generic parsers
     that you can use to parse... well, things that they are named 
after. Some
     of those ? like ?integer? ? are occasionally useful even if you're not
     parsing any languages (how often did you have to write ?read <$> many1
     digit?? now you don't have to).

   * ?skipLineComment? and ?skipBlockComment? generate comment parsers, and
     ?space? combines them together. You can make comment parsers
     arbitrarily complex before passing them to ?space?, or you can write
     your own space-skipping combinator.

   * ?lexeme?, ?symbol?, and ?symbol'? make lexemes out of things; a lexeme,
     by convention, expects no leading whitespace and skips all trailing
     whitespace.

So, instead of having parsers being passed to each other under the hood,
you now have to pass them by yourself ? except that you don't actually have
to do much passing, because you can just write

     import qualified Text.Megaparsec.Lexer as L

     lexeme = L.lexeme space
     symbol = L.symbol space

and off you go:

     keyword = label "keyword" . symbol
     parens = between (symbol "(") (symbol ")")
     ... etc ...

How you can help
~~~~~~~~~~~~~~~~

* Take a project, modify it to use Megaparsec, file an issue if you've
   encountered any difficulties.

* Take a Parsec tutorial and rewrite it for Megaparsec. (And then please
   send an email so that a link to your tutorial could be added to the
   README file.)

* As I've already mentioned before, if you have any ideas about what could
   be changed/improved in Parsec, they likely apply to Megaparsec as well ?
   propose them on the issue tracker.

* Report typos in documentation (same goes for mistakes, unclear phrasing,
   etc). If you're shy (like me) and don't like opening issues, just ping me
   on IRC (I'm ?indiagreen? on Freenode) if you spot anything.


From jeffbrown.the at gmail.com  Tue Sep 29 19:25:01 2015
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Tue, 29 Sep 2015 12:25:01 -0700
Subject: [Haskell-cafe] Parsing, infixes and on-the-fly precedence
In-Reply-To: <CAPY+ZdRDU_+24AEguqSWJMkHezvjt5GnG-AKioKgpaunbEHAxw@mail.gmail.com>
References: <CAEc4Ma2gEcuE+pv-PDUrs+Ofmwvo+Eak-_VG+uHBRh4hu2vxRw@mail.gmail.com>
 <CAPY+ZdRDU_+24AEguqSWJMkHezvjt5GnG-AKioKgpaunbEHAxw@mail.gmail.com>
Message-ID: <CAEc4Ma0KaaJ=MMuEW2h7xNBLa530gHqQcqDwL0sun45AerGKPg@mail.gmail.com>

Chris I thanked in private. Perhaps I should have done that publicly; it
looks like the Parsec.Expr library is exactly what I need.

Kim-Ee, yes, I believe that's exactly what I'm going for.

On Mon, Sep 28, 2015 at 8:07 PM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

>
> On Mon, Sep 28, 2015 at 2:28 PM, Jeffrey Brown <jeffbrown.the at gmail.com>
> wrote:
>
>> I imagine a parser that operates on (String,[String]) pairs, for which
>> the second element allows the user to define precedence on the fly.
>
>
> Let's use the Parser newtype
>
> newtype Parser a = Parser { parse :: String -> [(a,String)] }
>
> from
>
> http://dev.stephendiehl.com/fun/002_parsers.html
>
> as a basis for discussion.
>
> Now you want to "operate on (String,[String]) pairs", so the Parser
> newtype must now look like this:
>
> type MyInput = (String,[String])
>
> newtype MyParser a = MyParser { parse :: MyInput -> [(a,MyInput)] }
>
> Is this what you have in mind?
>
> -- Kim-Ee
>



-- 
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150929/a98c73ff/attachment.html>

From achudnov at gmail.com  Tue Sep 29 19:46:38 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Tue, 29 Sep 2015 15:46:38 -0400
Subject: [Haskell-cafe]
 =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?=
 =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?=
In-Reply-To: <560ADBAF.3060006@artyom.me>
References: <560ADBAF.3060006@artyom.me>
Message-ID: <560AEA9E.9050502@gmail.com>

(Artyom, I hope you can forward the following to the original author 
and, ideally, have them subscribe to the mailing list)

As a heavy user of parsec, I have to say this is simply awesome. I've 
read through the announcement and the changelog, and I have to say the 
changes seem to be spot on and scratch so many old itches I have 
personally struggled with when using parsec. I'm at the point where I am 
seriously considering porting all my code to megaparsec; however, lack 
of compatibility with GHC <7.10 is a bit of a deal-breaker at this point.

I'd like to discuss the decision to fork parsec. Now, I'm not judging: 
as long as the license permits it, whether to fork or not is really up 
to the forker.

However, it seems the author of megaparsec would like it to become the 
new standard parsing library (see "How you can help"). I'd like that 
too. However, I don't think that forking is the best way to achieve 
that. Of the two reasons that were given here, the first (stagnant 
development and maintenance) is a good reason to become either a 
co-maintainer, or a new maintainer. There seems to be a pretty smooth 
process for that now, and it doesn't raise any eyebrows when someone 
requests to be the new maintainer having good reasons for it (like 
willingness to contribute time and effort to the package).

The second reason is backwards compatibility. It's true the changes 
might break some code, but that's why we have major versions. And the 
overall architecture and interface is still in line with parsec. So, to 
me it makes perfect sense to call megaparsec a parsec-4.0.0.0 and get 
some continuity from the older library. That way megaparsec becomes the 
default just by inheritance.

So, if the author of megaparsec is open to becoming a maintainer of 
parsec, I'm sure the Hackage Trustees would be willing to help. If not, 
I'm personally willing to champion that.

/Andrey

On 09/29/2015 02:42 PM, Artyom wrote:
> Hello!
>
> I'd like to announce the release of Megaparsec, a fork of Parsec that has
> been in the works for the past 2 months. There's a lot of improvements 
> and
> bugfixes under the hood ? as well as a new test suite with 128 Quickcheck
> tests covering 80% of code (Parsec has only 3 tests, by the way) ? but 
> first
> I'd like to explain why a fork was needed, since forking a popular 
> library is
> a pretty drastic measure and should be accompanied by an explanation. (A
> disclaimer: I've been given permission to announce the library, but I'm
> neither the author nor an expert on parsing.)
> [..snip..]

From aditya.siram at gmail.com  Tue Sep 29 21:18:10 2015
From: aditya.siram at gmail.com (aditya siram)
Date: Tue, 29 Sep 2015 16:18:10 -0500
Subject: [Haskell-cafe] 7.10.2 : Compilation slowdown.
Message-ID: <CAJrReyiQPKhaCLaX+gjFp-d6evQsUzYBUUC_GM2yq8eqS3dcMw@mail.gmail.com>

Hi all,
Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase in
compilation time. I understand this is a known issue but since I'm seeing
something like a 3x slowdown but not across the board, I thought I'd ask.

Compilation time for the library I'm writing has remained about the same. I
am seeing the slowdown when compiling executables that use the library.
There are no other dependencies except base so I'm guessing it something in
my library causing the issue.

I lean heavily on the FFI, OverlappingInstances and HList style programming
in my library which leads me to believe that one of these is causing it. I
am seeing no difference in compilation speeds by adding the per instance
OVERLAPPING pragmas.

Can anyone advise or instruct me on how to profile the compiler?

Thanks!
-deech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150929/97032515/attachment.html>

From lanablack at amok.cc  Tue Sep 29 21:33:27 2015
From: lanablack at amok.cc (Lana Black)
Date: Tue, 29 Sep 2015 21:33:27 +0000
Subject: [Haskell-cafe] Data.Foldable.all and empty list
Message-ID: <20150929213327.GA10685@glow>

Hello,

Is there any particular reason why the 'all' function returns True when
supplied with an empty list (or any other foldable)? I'm aware that it
is implemented via All monoid instance, my question is whether this
behaviour is intentional or it can be considered a bug.

From kane at kane.cx  Tue Sep 29 21:37:19 2015
From: kane at kane.cx (David Kraeutmann)
Date: Tue, 29 Sep 2015 23:37:19 +0200
Subject: [Haskell-cafe] Data.Foldable.all and empty list
In-Reply-To: <20150929213327.GA10685@glow>
References: <20150929213327.GA10685@glow>
Message-ID: <560B048F.1080503@kane.cx>

Completely intentional.
'all' tests whether the predicate is true for all elements; if there are no elements, it's vacuously true (cf. forall quantifier in logic).

On 9/29/2015 11:33 PM, Lana Black wrote:
> Hello,
>
> Is there any particular reason why the 'all' function returns True when
> supplied with an empty list (or any other foldable)? I'm aware that it
> is implemented via All monoid instance, my question is whether this
> behaviour is intentional or it can be considered a bug.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150929/3c48d4e3/attachment.bin>

From tikhon at jelv.is  Tue Sep 29 21:43:02 2015
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Tue, 29 Sep 2015 14:43:02 -0700
Subject: [Haskell-cafe] Data.Foldable.all and empty list
In-Reply-To: <20150929213327.GA10685@glow>
References: <20150929213327.GA10685@glow>
Message-ID: <CAJN5CVLJY6Bxuy8L3=_F+11mz7XvpS_YAi6s6XiHR6B3mC40jA@mail.gmail.com>

It's intentional. The behavior makes sense (although it's a bit unintuitive
at first) and follows common mathematical convention.

For one, it makes sense logically: it is vacuously true that every element
of an empty list satisfies any predicate. That's how forall works normally.
Think about it by analogy to implication: false implies anything (ie False
-> a is true no matter what a is).

It also makes sense when looking at these as a fold: the folding operation
is && and True is the identity element for &&. In a broad sense, True is
naturally the "empty" case for && so that's where we start from. It's the
same for say sum (an empty sum is 0) and product (an empty product is 1).

>From a practical standpoint, this default neatly avoids a bunch of special
cases, meaning we don't have to check if a list is empty before aggregating
it. It's something that's worth understanding and relying in because it
makes your code simpler and more regular.
On Sep 29, 2015 14:33, "Lana Black" <lanablack at amok.cc> wrote:

> Hello,
>
> Is there any particular reason why the 'all' function returns True when
> supplied with an empty list (or any other foldable)? I'm aware that it
> is implemented via All monoid instance, my question is whether this
> behaviour is intentional or it can be considered a bug.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150929/ca399a41/attachment.html>

From tonymorris at gmail.com  Tue Sep 29 22:54:12 2015
From: tonymorris at gmail.com (Tony Morris)
Date: Wed, 30 Sep 2015 08:54:12 +1000
Subject: [Haskell-cafe] Data.Foldable.all and empty list
In-Reply-To: <20150929213327.GA10685@glow>
References: <20150929213327.GA10685@glow>
Message-ID: <560B1694.6010501@gmail.com>

All the spiders in my hand are purple. There are no spiders in my hand.


On 30/09/15 07:33, Lana Black wrote:
> Hello,
> 
> Is there any particular reason why the 'all' function returns True when
> supplied with an empty list (or any other foldable)? I'm aware that it
> is implemented via All monoid instance, my question is whether this
> behaviour is intentional or it can be considered a bug.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 

From ky3 at atamo.com  Wed Sep 30 04:04:35 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Wed, 30 Sep 2015 11:04:35 +0700
Subject: [Haskell-cafe] Data.Foldable.all and empty list
In-Reply-To: <20150929213327.GA10685@glow>
References: <20150929213327.GA10685@glow>
Message-ID: <CAPY+ZdTn6TLPVMF=CYf3KXHaYApOoFtk-a-7nmAsVDZN9h06mQ@mail.gmail.com>

On Wed, Sep 30, 2015 at 4:33 AM, Lana Black <lanablack at amok.cc> wrote:

> Is there any particular reason why the 'all' function returns True when
> supplied with an empty list (or any other foldable)? I'm aware that it
> is implemented via All monoid instance, my question is whether this
> behaviour is intentional or it can be considered a bug.
>

Hi Lana, this is a good question, variants of which are actually asked
quite often.

The function 'all' has type signature (a -> Bool) -> [a] -> Bool.

Given a list of as that's split arbitrarily into bs and cs such that as ==
bs ++ cs,
'all' has the property that: all p as == all p bs && all p cs, for any
boolean predicate p.

So if bs or cs is the empty list, the property forces all f [] == True.

For a similar Q&A on related functions, see

https://groups.google.com/forum/#!msg/elm-discuss/sPS98RnV0Og/dSddTp8VXYcJ

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/cc0c7364/attachment.html>

From charles at voleon.com  Wed Sep 30 04:12:59 2015
From: charles at voleon.com (Charles Weitzer)
Date: Wed, 30 Sep 2015 04:12:59 +0000
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning Startup
Message-ID: <DM3PR1201MB09913EDC86D6B84CFC6622D9C64D0@DM3PR1201MB0991.namprd12.prod.outlook.com>

Voleon Capital Management LP is a startup quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer with strong functional programming experience as soon as possible.
Voleon's founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon's team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well.
Here is our formal job description:
**********************************************************
* Senior Software Engineer *
Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems.
The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm's offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, catered lunches, and competitive benefits packages.
We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus.
We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential.
Required experience:
- strong experience developing in a functional programming environment (Haskell, Erlang, others).
- developing with C/C++/Python/Go in a Linux environment with a focus on performance, concurrency, and correctness.
- working in TCP/IP networking, multi-threading, and server development.
- working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.).
- architecting and designing highly available systems.
- architecting and designing large-scale data management infrastructure.
- working in large codebases and building modular, manageable code.
Preferred experience.:
- debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc.
- working with build and test automation tools.
- working with well-defined change management processes.
- diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc.
- working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems.
Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring.
Benefits and compensation are highly competitive.
**********************************************************
The above job description is just a starting point in terms of possible duties and seniority.  We can be very flexible for the right person.
If you are interested please apply on our website: http://voleon.com/apply/.
If you have any questions or  if you know of anyone who might be interested, let us know the best way to get in touch and we can discuss details.
Thank you,

Charles Weitzer
Senior Recruiter
Voleon Capital Management LP
Office: 510.704.9870 x 7012
Mobile: (510) 558-9182
www.Voleon.com<http://www.voleon.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/340e9588/attachment.html>

From ky3 at atamo.com  Wed Sep 30 06:44:27 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Wed, 30 Sep 2015 13:44:27 +0700
Subject: [Haskell-cafe] Haskell Weekly News
Message-ID: <CAPY+ZdTFKBNBKX6UMY46ZE91RhHaXMqtOnijbSq=M3zYa-cu2Q@mail.gmail.com>

*Top picks:*

   - Neil Mitchell reports a stack overflow with 7.10.2 maximumBy
   <https://ghc.haskell.org/trac/ghc/ticket/10830> that regresses from
   7.8.3. His sixth sense points to the Foldable-Traversable coup
   <https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP> (aka BBP: Burning
   Bridges Proposal) as culprit. Joachim Breitner investigates and verifies
   that the bug's indeed caused by BBP's redefinition of maximumBy that
   changed out foldl1 for foldr1. Neil guesses that with foldl1, "the
   strictness analysis managed to kick in and optimise things." Joachim opines
   that "this is more a BBP design issue than a compiler bug." For now, roll
   your own maximumBy if you're affected.

   - A reddit question
   <https://www.reddit.com/r/haskell/comments/3jvyf7/services_for_learners/>
   asks whether there's a way for "haskell learners to learn haskell from
   haskell gurus, one-on-one for a fee?" An answer points to CodeMentor
   <https://www.codementor.io/haskell-experts> where haskellers charge from
   $15 to $60 per quarter-hour of consultation. Heinrich Apfelmus chimes in to
   say he's at HackHands <https://hackhands.com/>.

   - Yair Chuchem, who worked at Google for a year, reveals
   <https://www.reddit.com/r/haskell/comments/3ij91q/who_works_at_google_and_how_is_it/cuhczzx>
   how a software engineer's performance metric is gamed to the detriment of
   the Organizer of the World's Information. Not quite Wally's "I'm gonna
   write me a new minivan this afternoon"
   <http://dilbert.com/strip/1995-11-13> but close. To the indignation of
   his managers, Yair left Google to work with Eyal Lotem on his passion: an
   Abstract-Syntax-Tree-driven IDE called Lamdu
   <http://peaker.github.io/lamdu/>, which redditors have already unpacked
   here
   <https://www.reddit.com/r/haskell/comments/3k8ek3/lamdu_blog_designing_programming_languages_with/>
   .

   - Ph.D. student Rob Zinkov
   <http://zinkov.com/posts/2015-08-25-building-a-probabilisitic-interpreter/>
   demoes a rudimentary Probabilistic Programming Interpreter based on
   importance sampling.



*Quotes of the Week:*

   - User kyllo on HN:
   <https://news.ycombinator.com/item?id=10276498#up_10277862> It's an
   exciting time for Haskell developers right now, we just got an a awesome
   new build tool (stack), an incredible new server-side framework (servant)
   and our compile to JS tool (GHCJS) is improving by leaps and bounds.

   - @gfixler: Was OOP created as a business model to sell complex tooling?
   @jonruttenberg:
   <https://twitter.com/jonruttenberg/status/638329205483249664> @gfixler
   Was #haskell created as a business model to sell complex blog posts?

   - User breadbox on HN observes:
   <https://news.ycombinator.com/item?id=10122333#up_10126413> "People
   think that confidence follows skills, but it?s usually the other way around
   where skills follow confidence." This is a fact that really needs to be
   more widely acknowledged. (It also casts the microagressions that have the
   effect of chipping away at the confidence of women and minorities in a
   rather uncomfortable light.)

   - User mgrennan on HN:
   <https://news.ycombinator.com/item?id=10122784#up_10123667>I understand
   it is our nature to push away from parents to strike out on our own. I also
   understand why older people resist change. Magic happens when the young
   seek to understand the wisdom of their elders and elders hold on to
   explorer spirit of their youth.


-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/b7f57080/attachment.html>

From carter.schonwald at gmail.com  Wed Sep 30 13:47:16 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 30 Sep 2015 09:47:16 -0400
Subject: [Haskell-cafe] 7.10.2 : Compilation slowdown.
In-Reply-To: <CAJrReyiQPKhaCLaX+gjFp-d6evQsUzYBUUC_GM2yq8eqS3dcMw@mail.gmail.com>
References: <CAJrReyiQPKhaCLaX+gjFp-d6evQsUzYBUUC_GM2yq8eqS3dcMw@mail.gmail.com>
Message-ID: <CAHYVw0yD_O2gFQC+cJThvoLuSgKNYfd+KQ7t8XyNaCp3naUOPw@mail.gmail.com>

Have you checked how changing the optimization level affects build times?
Are you using template Haskell?

On Tuesday, September 29, 2015, aditya siram <aditya.siram at gmail.com> wrote:

> Hi all,
> Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase in
> compilation time. I understand this is a known issue but since I'm seeing
> something like a 3x slowdown but not across the board, I thought I'd ask.
>
> Compilation time for the library I'm writing has remained about the same.
> I am seeing the slowdown when compiling executables that use the library.
> There are no other dependencies except base so I'm guessing it something in
> my library causing the issue.
>
> I lean heavily on the FFI, OverlappingInstances and HList style
> programming in my library which leads me to believe that one of these is
> causing it. I am seeing no difference in compilation speeds by adding the
> per instance OVERLAPPING pragmas.
>
> Can anyone advise or instruct me on how to profile the compiler?
>
> Thanks!
> -deech
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/89e9de02/attachment.html>

From svenpanne at gmail.com  Wed Sep 30 14:29:12 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 30 Sep 2015 16:29:12 +0200
Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
Message-ID: <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>

After some discussions via email and via the Wiki (
https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl),
I've already made a few changes to OpenGLRaw, bringing it closer to 'gl'.
These are fully backwards compatible, because they mainly consist of
improvements in the generated documentation and the addition of various
extension-related retrieval functions. Before I move on and introduce
breaking changes, I'd like to hear some opinions about a few items which
might need some more discussion:

  * Should OpenGLRaw use pattern synonyms? (Probably yes, but note that
this implies GHC >= 7.8.1)

  * Should OpenGLRaw use the 'Half' type from the 'half' package? (Probably
yes, but again this implies GHC 7.8.1)

  * Should the incredibly long 'Graphics.Rendering.OpenGL.Raw' module
prefix be replaced by the more palatable 'Graphics.GL.Raw'? (Probably yes)

More details and other already resolved and/or less controversial items can
be found on the Wiki. The plan is to release a new OpenGLRaw version soon
(3.0), after which Edward and Gabr?el Arth?r can deprecate the 'gl' package
(if they like).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/8c70fd1f/attachment.html>

From cam at uptoisomorphism.net  Wed Sep 30 15:02:15 2015
From: cam at uptoisomorphism.net (Casey McCann)
Date: Wed, 30 Sep 2015 11:02:15 -0400
Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
Message-ID: <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>

On Wed, Sep 30, 2015 at 10:29 AM, Sven Panne <svenpanne at gmail.com> wrote:
>   * Should OpenGLRaw use pattern synonyms? (Probably yes, but note that this
> implies GHC >= 7.8.1)
>
>   * Should OpenGLRaw use the 'Half' type from the 'half' package? (Probably
> yes, but again this implies GHC 7.8.1)

7.8.1 is, what, a year and a half old?

I'm all for bleeding edge personally but not everyone feels that way,
and that seems pretty severe relative to the benefits.

That said, I don't actually have any specific arguments against
requiring GHC >= 7.8.1 since I'm fine with it myself and, as mentioned
on the wiki, it's not like the older package versions will disappear.

As an aside regarding the wiki discussion, I don't really see how
there's a sane way to have a combined low-level API for WebGL and full
OpenGL. At least as of last time I did anything with it, there are a
huge number of minor differences in the API that I don't know how
you'd paper over. If anything, WebGL might be a good role model to
imitate for a slightly higher level, less fiddly but still directly
mapped to the underlying layer, API for GL.

I'm sure Edward had some plan for how to add WebGL support, but short
of having a completely separate set of modules for it I can't imagine
how it'd work.

- C.

From svenpanne at gmail.com  Wed Sep 30 17:38:26 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 30 Sep 2015 19:38:26 +0200
Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
 <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
Message-ID: <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>

2015-09-30 17:02 GMT+02:00 Casey McCann <cam at uptoisomorphism.net>:

> On Wed, Sep 30, 2015 at 10:29 AM, Sven Panne <svenpanne at gmail.com> wrote:
> >   * Should OpenGLRaw use pattern synonyms? (Probably yes, but note that
> this
> > implies GHC >= 7.8.1)
> >
> >   * Should OpenGLRaw use the 'Half' type from the 'half' package?
> (Probably
> > yes, but again this implies GHC 7.8.1)
>
> 7.8.1 is, what, a year and a half old?
>
> I'm all for bleeding edge personally but not everyone feels that way,
> and that seems pretty severe relative to the benefits.
>

That's my biggest concern, too, and that's why I wanted to hear other
people's opinions: IMHO using pattern synonyms vs. plain old Haskell values
is to a large part just bikeshedding, at least in the trivial case at hand
where we talk about simple integral values. It basically boils down to the
question: Is

   foo x = case x of
     GL_BAR -> expr1
     GL_BAZ -> expr2
     _ -> expr3

really so much better than

   foo x
     | x == GL_BAR = expr1
     | x == GL_BAZ = expr2
     | otherwise = expr3

that we want to drop support for GHC < 7.8.1? Personally, I'm not
convinced, but if most other people think that it's OK, I'm willing to pay
the price for the sake of merging the packages. Edward claims that using
pattern synonyms will result in more efficient code, too, but I haven't
checked that. And even if it was: Perhaps GHC can be tweaked to treat both
versions above in the same way (I can see no reason why this shouldn't be
possible, but perhaps I'm wrong). Regarding readability: The version with
pattern synonyms *is* slightly more readable, but not so much that it would
warrant dropping slightly outdated GHCs.

Regarding the 'half' package: I've just seen that it should work with any
GHC 7.x now, so this decision can be decoupled from the pattern synonym
issue. Perhaps I should release a new, only slightly incompatible OpenGLRaw
version using 'half'? Although GLhalf is part of OpenGL core since 3.0, it
is only used in very few non-central places (GL_ARB_half_float_pixel,
GL_ARB_half_float_vertex, and GL_NV_half_float). So the resulting breakage
will probably be very low.

Regarding the module prefix: I'm not sure if it's worth making this
breaking change alone, probably this should only be done in conjunction
with the introduction of pattern synonyms. But other opinions would be
valuable here, too.

[...] As an aside regarding the wiki discussion, I don't really see how
> there's a sane way to have a combined low-level API for WebGL and full
> OpenGL. [...]


As already mentioned in more detail on the Wiki, the plan to combine OpenGL
and WebGL in a single package is doomed: Different values for the same
token, different contents of the extensions, different ways to retrieve the
entry points. It's a pity, but that's how it is...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/f8a31548/attachment.html>

From zocca.marco at gmail.com  Wed Sep 30 17:51:31 2015
From: zocca.marco at gmail.com (Marco Zocca)
Date: Wed, 30 Sep 2015 19:51:31 +0200
Subject: [Haskell-cafe] Initial public release of Haskell bindings for SLEPc
Message-ID: <CAKE6T0S7m-7damDYh-A=2JaK+Md17yxx1ZVS_VU+giDh=sAzJw@mail.gmail.com>

Dear all,

    I have published the first version of my Haskell bindings for the
SLEPc parallel eigenproblem library; it's available at

https://github.com/ocramz/slepc-hs

So far, only the most basic functionality is wrapped, and there is no
exception control or high-level types and combinators, but it
showcases a number of aspects of Haskell foreign-function interface
design (using `inline-c`). I am also developing Haskell bindings for
PETSc, thanks to the similar design of the two libraries, and I hope
to release it before the end of the year.

My biggest hope however is to contribute to the conversation between
the functional programming and high-performance computing communities,
as I feel the expressiveness and correctness guarantees provided by
the former can be of great advantage to the latter.

I look forward to your feedback;
Kind regards,

Marco Zocca

From nicola.gigante at gmail.com  Wed Sep 30 18:27:01 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Wed, 30 Sep 2015 20:27:01 +0200
Subject: [Haskell-cafe]
 =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?=
 =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?=
In-Reply-To: <560AEA9E.9050502@gmail.com>
References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com>
Message-ID: <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com>


> Il giorno 29/set/2015, alle ore 21:46, Andrey Chudnov <achudnov at gmail.com> ha scritto:
> 
> (Artyom, I hope you can forward the following to the original author and, ideally, have them subscribe to the mailing list)
> 
> As a heavy user of parsec, I have to say this is simply awesome. I've read through the announcement and the changelog, and I have to say the changes seem to be spot on and scratch so many old itches I have personally struggled with when using parsec. I'm at the point where I am seriously considering porting all my code to megaparsec; however, lack of compatibility with GHC <7.10 is a bit of a deal-breaker at this point.
> 
> I'd like to discuss the decision to fork parsec. Now, I'm not judging: as long as the license permits it, whether to fork or not is really up to the forker.
> 
> However, it seems the author of megaparsec would like it to become the new standard parsing library (see "How you can help"). I'd like that too. However, I don't think that forking is the best way to achieve that. Of the two reasons that were given here, the first (stagnant development and maintenance) is a good reason to become either a co-maintainer, or a new maintainer. There seems to be a pretty smooth process for that now, and it doesn't raise any eyebrows when someone requests to be the new maintainer having good reasons for it (like willingness to contribute time and effort to the package).
> 
> The second reason is backwards compatibility. It's true the changes might break some code, but that's why we have major versions. And the overall architecture and interface is still in line with parsec. So, to me it makes perfect sense to call megaparsec a parsec-4.0.0.0 and get some continuity from the older library. That way megaparsec becomes the default just by inheritance.
> 
> So, if the author of megaparsec is open to becoming a maintainer of parsec, I'm sure the Hackage Trustees would be willing to help. If not, I'm personally willing to champion that.
> 
> /Andrey
> 

+1

Megaparsec seems awesome to me, especially the monad transformers issue
is exactly what I missed in using Parsec.

As someone that often teaches a bit of haskell, I would also like it to become 
"Parsec 4.0? if that?s possible. That would save a lot of boilerplate in docs and
tutorials about why I?m talking about megaparsec while it seems the most used
library is parsec and explain the reasons of the fork etc.. every time.

To megaparsec?s author: great work!


Bye,
Nicola

From carter.schonwald at gmail.com  Wed Sep 30 19:32:26 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 30 Sep 2015 15:32:26 -0400
Subject: [Haskell-cafe]
	=?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?=
	=?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?=
In-Reply-To: <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com>
References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com>
 <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com>
Message-ID: <CAHYVw0yVwcPmxP7oo81-Ag73ewESsK00-KYRozcaO6dDO3fR1Q@mail.gmail.com>

Agreed. Great work, and if we can find a path to this being a foundation
for or inspiring parsec 4.0, that would probably be a net win for everyone.

On Wednesday, September 30, 2015, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

>
> > Il giorno 29/set/2015, alle ore 21:46, Andrey Chudnov <
> achudnov at gmail.com <javascript:;>> ha scritto:
> >
> > (Artyom, I hope you can forward the following to the original author
> and, ideally, have them subscribe to the mailing list)
> >
> > As a heavy user of parsec, I have to say this is simply awesome. I've
> read through the announcement and the changelog, and I have to say the
> changes seem to be spot on and scratch so many old itches I have personally
> struggled with when using parsec. I'm at the point where I am seriously
> considering porting all my code to megaparsec; however, lack of
> compatibility with GHC <7.10 is a bit of a deal-breaker at this point.
> >
> > I'd like to discuss the decision to fork parsec. Now, I'm not judging:
> as long as the license permits it, whether to fork or not is really up to
> the forker.
> >
> > However, it seems the author of megaparsec would like it to become the
> new standard parsing library (see "How you can help"). I'd like that too.
> However, I don't think that forking is the best way to achieve that. Of the
> two reasons that were given here, the first (stagnant development and
> maintenance) is a good reason to become either a co-maintainer, or a new
> maintainer. There seems to be a pretty smooth process for that now, and it
> doesn't raise any eyebrows when someone requests to be the new maintainer
> having good reasons for it (like willingness to contribute time and effort
> to the package).
> >
> > The second reason is backwards compatibility. It's true the changes
> might break some code, but that's why we have major versions. And the
> overall architecture and interface is still in line with parsec. So, to me
> it makes perfect sense to call megaparsec a parsec-4.0.0.0 and get some
> continuity from the older library. That way megaparsec becomes the default
> just by inheritance.
> >
> > So, if the author of megaparsec is open to becoming a maintainer of
> parsec, I'm sure the Hackage Trustees would be willing to help. If not, I'm
> personally willing to champion that.
> >
> > /Andrey
> >
>
> +1
>
> Megaparsec seems awesome to me, especially the monad transformers issue
> is exactly what I missed in using Parsec.
>
> As someone that often teaches a bit of haskell, I would also like it to
> become
> "Parsec 4.0? if that?s possible. That would save a lot of boilerplate in
> docs and
> tutorials about why I?m talking about megaparsec while it seems the most
> used
> library is parsec and explain the reasons of the fork etc.. every time.
>
> To megaparsec?s author: great work!
>
>
> Bye,
> Nicola
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/6e4ea760/attachment.html>

From aditya.siram at gmail.com  Wed Sep 30 22:25:03 2015
From: aditya.siram at gmail.com (aditya siram)
Date: Wed, 30 Sep 2015 17:25:03 -0500
Subject: [Haskell-cafe] 7.10.2 : Compilation slowdown.
In-Reply-To: <CAHYVw0yD_O2gFQC+cJThvoLuSgKNYfd+KQ7t8XyNaCp3naUOPw@mail.gmail.com>
References: <CAJrReyiQPKhaCLaX+gjFp-d6evQsUzYBUUC_GM2yq8eqS3dcMw@mail.gmail.com>
 <CAHYVw0yD_O2gFQC+cJThvoLuSgKNYfd+KQ7t8XyNaCp3naUOPw@mail.gmail.com>
Message-ID: <CAJrReyhoC_crGMMdveMS7siV_qjYg3fQnKqX5fdEq1P-KWAdBQ@mail.gmail.com>

I'm not using any -O* flags and I'm not using Template Haskell. Not sure if
this means anything but I do have the context-stack set to 220.

Thanks!
-deech

On Wed, Sep 30, 2015 at 8:47 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Have you checked how changing the optimization level affects build times?
> Are you using template Haskell?
>
>
> On Tuesday, September 29, 2015, aditya siram <aditya.siram at gmail.com>
> wrote:
>
>> Hi all,
>> Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase in
>> compilation time. I understand this is a known issue but since I'm seeing
>> something like a 3x slowdown but not across the board, I thought I'd ask.
>>
>> Compilation time for the library I'm writing has remained about the same.
>> I am seeing the slowdown when compiling executables that use the library.
>> There are no other dependencies except base so I'm guessing it something in
>> my library causing the issue.
>>
>> I lean heavily on the FFI, OverlappingInstances and HList style
>> programming in my library which leads me to believe that one of these is
>> causing it. I am seeing no difference in compilation speeds by adding the
>> per instance OVERLAPPING pragmas.
>>
>> Can anyone advise or instruct me on how to profile the compiler?
>>
>> Thanks!
>> -deech
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/c20f05a2/attachment.html>

From capn.freako at gmail.com  Wed Sep 30 22:54:23 2015
From: capn.freako at gmail.com (David Banas)
Date: Wed, 30 Sep 2015 15:54:23 -0700
Subject: [Haskell-cafe] Haskell-Cafe Digest, Vol 145, Issue 41
In-Reply-To: <mailman.8491.1443542926.13545.haskell-cafe@haskell.org>
References: <mailman.8491.1443542926.13545.haskell-cafe@haskell.org>
Message-ID: <A6422A85-193F-4C31-88B9-66C59998DA1E@gmail.com>

Thanks for your reply, Tom.

That last expression doesn?t seem to have the correct type:

Prelude Control.Applicative> let l1 = \x f -> pure f <*> x
Prelude Control.Applicative> :t l1
l1 :: Applicative f => f a -> (a -> b) -> f b
Prelude Control.Applicative> let l2 = \x f -> fmap f x
Prelude Control.Applicative> :t l2
l2 :: Functor f => f a -> (a -> b) -> f b
Prelude Control.Applicative> let l3 = \x f -> ($ x) <*> pure f
Prelude Control.Applicative> :t l3
l3 :: a1 -> a -> (a1 -> a -> b) -> b

Is there a typo?

Thanks,
-db

On Sep 29, 2015, at 9:08 AM, haskell-cafe-request at haskell.org wrote:

> Message: 2
> Date: Tue, 29 Sep 2015 16:40:38 +0100
> From: Tom Ellis <tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] Question, re: Typeclassopedia Ex. 4.2.1
> Message-ID: <20150929154037.GS14111 at weber>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Sep 29, 2015 at 07:48:05AM -0700, David Banas wrote:
>> pure (flip ($)) <*> x <*> pure f     = (interchange)
>> pure (flip ($)) <*> pure ($ f) <*> x = (homomorphism)
> 
> For one thing, this step doesn't look right.   <*> does not associate that
> way.
> 
> It's probably worth at least putting each expression into ghci to check they
> have the same time
> 
>    Prelude> import Control.Applicative
>    Prelude Control.Applicative> let l = \x f -> pure (flip ($)) <*> x <*> pure f
>    Prelude Control.Applicative> :t l
>    l :: Applicative f => f a -> (a -> b) -> f b
>    Prelude Control.Applicative> let l2 = \x f -> pure (flip ($)) <*> pure ($ f) <*> x
>    Prelude Control.Applicative> :t l2
>    l2 :: Applicative f => f (((a -> b1) -> b1) -> b) -> a -> f b
> 
> I imagine you're probably going to want to go via ($ x) rather than ($ f),
> and possibly use that 'pure f <*> x = fmap f x = ($ x) <*> pure f'.
> 
> Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/a9306a98/attachment.html>

From kane at kane.cx  Wed Sep 30 23:22:34 2015
From: kane at kane.cx (David Kraeutmann)
Date: Thu, 1 Oct 2015 01:22:34 +0200
Subject: [Haskell-cafe] 7.10.2 : Compilation slowdown.
In-Reply-To: <CAJrReyhoC_crGMMdveMS7siV_qjYg3fQnKqX5fdEq1P-KWAdBQ@mail.gmail.com>
References: <CAJrReyiQPKhaCLaX+gjFp-d6evQsUzYBUUC_GM2yq8eqS3dcMw@mail.gmail.com>
 <CAHYVw0yD_O2gFQC+cJThvoLuSgKNYfd+KQ7t8XyNaCp3naUOPw@mail.gmail.com>
 <CAJrReyhoC_crGMMdveMS7siV_qjYg3fQnKqX5fdEq1P-KWAdBQ@mail.gmail.com>
Message-ID: <CAJ8B99z6RVov8xhSjTsRn2YYRvvL6qhz0R47MhOeOCVwu+mfzw@mail.gmail.com>

Can you post a minimal example that exhibits the compile time increase?

On Thu, Oct 1, 2015 at 12:25 AM, aditya siram <aditya.siram at gmail.com> wrote:
> I'm not using any -O* flags and I'm not using Template Haskell. Not sure if
> this means anything but I do have the context-stack set to 220.
>
> Thanks!
> -deech
>
> On Wed, Sep 30, 2015 at 8:47 AM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>>
>> Have you checked how changing the optimization level affects build times?
>> Are you using template Haskell?
>>
>>
>> On Tuesday, September 29, 2015, aditya siram <aditya.siram at gmail.com>
>> wrote:
>>>
>>> Hi all,
>>> Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase in
>>> compilation time. I understand this is a known issue but since I'm seeing
>>> something like a 3x slowdown but not across the board, I thought I'd ask.
>>>
>>> Compilation time for the library I'm writing has remained about the same.
>>> I am seeing the slowdown when compiling executables that use the library.
>>> There are no other dependencies except base so I'm guessing it something in
>>> my library causing the issue.
>>>
>>> I lean heavily on the FFI, OverlappingInstances and HList style
>>> programming in my library which leads me to believe that one of these is
>>> causing it. I am seeing no difference in compilation speeds by adding the
>>> per instance OVERLAPPING pragmas.
>>>
>>> Can anyone advise or instruct me on how to profile the compiler?
>>>
>>> Thanks!
>>> -deech
>>>
>>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>