Re: [Haskell-cafe] smt solver bindings

[Levent Erkok]

Dimitrios:

The SBV library (http://hackage.haskell.org/package/sbv) can indeed
use Z3 as a backend SBV solver. However, it uses Z3 via SMT-Lib2, not
via it's C-API. It aims to provide a much higher level interface,
integrating with Haskell as smoothly as possible, keeping the
SMT-solver transparent to the user.

I'm actively developing and using SBV
(http://github.com/LeventErkok/sbv), so any comments/feedback would be
most welcome. Do let me know if you decide to use it and see any
issues..

-Levent.

On Thu, Dec 15, 2011 at 12:17 PM, Josef Svenningsson
 wrote:
> On Thu, Dec 15, 2011 at 7:04 PM, Dimitrios Vytiniotis
>  wrote:
>>
>>
>> I've a quick question:
>>
>> Are there Haskell wrappers for the Z3 C API around?
>>
> I believe sbv recently got support for Z3 but I don't know if it uses the C
> API. Neither have I tried the Z3 backend, I only played with the Yices
> backend. If you contact Levent Erkök, the author of sbv, he should be able
> to give you more information.
>
>  https://github.com/LeventErkok/sbv
>
> Thanks,
>
> Josef
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

[Ganesh Sittampalam]

Hi,

As mentioned in the committee's annual report
(http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our
attempt to join SFC has stalled because they don't have the capacity to
accept new projects at the moment.

We therefore applied to join SPI (http://www.spi-inc.org/), and they
have now offered us "associated project" status
(http://www.spi-inc.org/projects/associated-project-howto/).

We intend to accept this offer, but are taking this final opportunity to
seek feedback from the community before doing so.

SPI is very like SFC in what it does and how it operates, so we don't
expect this to make any substantial differences to the FAQ quoted below.

Regards,

Ganesh
on behalf of the haskell.org committee

On 10/05/2011 23:44, Don Stewart wrote:
> Hello everyone.
> 
> The haskell.org committee[1], in the interest of the long-term stability
> of the open source Haskell community infrastructure, has decided to
> incorporate haskell.org as a legal entity. This email outlines our
> recommendation, and seeks input from the community on this decision.
> 
> The committee's proposal is that haskell.org incorporate as an entity
> under the Software Freedom Conservancy umbrella organization (the same group
> that Darcs joined recently):
> 
> http://sfconservancy.org/
> 
> If we proceed with this move, haskell.org will be a legal entity, and
> registered as a non-profit, allowing us to more directly accept
> (US tax-deductible) donations, and to invest in assets that benefit the
> Haskell open source community.
> 
> We welcome your feedback on the proposal attached below.
> 
> -- Don Stewart (on behalf of the Haskell.org committee)
> 
> 
> 
> 
> 
> = A proposal for the incorporation of Haskell.org =
> 
> In recent years, haskell.org has started to receive assets, e.g. money from
> Google Summer Of Code, donations for Hackathons, and a Sparc machine for use 
> in
> GHC development. We have also started spending this money: in particular, on
> hosting haskell.org itself. There is also interest in running fundraising
> drives for specific things such as Hackathon sponsorship and hosting fees.
> 
> However, haskell.org doesn't currently exist as a legal entity, meaning that
> these assets have had to be held on our behalf by other entities, such as
> Galois and various universities. This leads to tricky situations, with no-one
> being sure who should decide how the haskell.org assets can be used.
> 
> To solve these problems, we propose that haskell.org applies to become a 
> member
> project of the Software Freedom Conservancy (SFC)
> . The SFC is a non-profit 
> organization
> that provides free financial and administrative services to open source
> projects. Additionally, it has 501(c)(3) status, meaning donations from the US
> are tax-deductible. The SFC would hold haskell.org's money and other assets,
> and would be able to accept donations on behalf of haskell.org.
> 
> The haskell.org committee, as described here [2], will make decisions on
> spending assets and other decisions related to governing the non-profit.
> 
> 
> Before proceeding, we are inviting input from the community in the form
> of specific objections or queries regarding the plan.
> 
> We've tried to answer some of the most likely questions:
> 
> Q: Does this mean that my Haskell project must now be covered by a
>  copyleft licence such as GPL?
> A: No, but Haskell projects using haskell.org resource should use an
> Open Source licence
>  .
> 
> Q: Will it still be possible to use community.h.o to host
>  non-open-source material, such as academic papers?
> A: An overall minority of such content, as is the current situation, is
> not a problem.
> 
> Q: Will it still be possible to have job ads on the haskell.org mailing
> lists and website?
> A: Yes.
> 
> Q: Will this affect our ability to host the Haskell Symposium
>   and Industrial Haskell
> Group  webpages within haskell.org?
> A: No.
> 
> Q: What will be the relationship between haskell.org and other
> organizations such as the Haskell Symposium and Industrial Haskell
> Group?
> A: Those organisations will continue to exist as separate entities.
> 
> Q: If an umbrella non-profit organisation "The Haskell Foundation" was
> created, would haskell.org be able to join it?
> A: Yes. It's likely that in such a scenario, the Haskell Foundation
> would become the owner of the haskell.org domain name, with the cost
> divided between the members. The entity that is part of the SFC would
> be renamed "community.haskell.org" in order to avoid confusion.
> 
> [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee
> [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation
> 
> __

Re: [Haskell-cafe] Parallel Matrix Multiplication

[Eric Kow]

Hi Mukesh,

Great to hear you're trying parallel Haskell! I can't yet help debug your 
parallel performance, but maybe I can offer something for your last request.

Have you tried the Parallel Haskell portal?

http://www.haskell.org/haskellwiki/Parallel

You will find some links mainly aimed at helping people to get started, and 
also a list of parallel Haskell readings.

Hope this helps :-)

On 10 Dec 2011, at 18:14, mukesh tiwari wrote:
> I am trying to learn parallel Haskell and  I have gone through couple of 
> resources ( Real world Haskell and 
> http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/AFP08-notes.pdf
>  ). I understood par and pseq and I wrote matrix multiplication using these 
> two function but it does not look.  Although I did not get all these details 
> but none of the sparks converted which is really important for parallel 
> programming.
> Could some one please tell me how to improve this.

> Also kindly recommend me some  literature for parallel programming in Haskell.

-- 
Eric Kow 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically

[Mikolaj Konarski]

On Mon, Oct 10, 2011 at 15:55, Tom Thorne  wrote:
> Yes I will try to run threadscope on it, I tried it before and the event log 
> output produced about 1.8GB, and then crashed.

Hi Tom,

I'm one of the TS/ghc-events hackers and I'd like to learn more,
fix it or at least put it on the TS/ghc-events issue tracker
(http://trac.haskell.org/ThreadScope). Could you help me reproduce
the problem? Did ThreadScope crash or RTS? Which versions?
Was it 1.8GB of the log file or RAM? Did you succeed eventually?
Any other TS feedback?

Thank you,
Mikolaj

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

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

[Ganesh Sittampalam]

BTW as with the Don's original message about incorporating, I
distributed this widely to increase awareness, but please restrict any
feedback to haskell-cafe@ and committee@.

Sorry for the noise!

Ganesh

On 16/12/2011 09:08, Ganesh Sittampalam wrote:
> Hi,
> 
> As mentioned in the committee's annual report
> (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our
> attempt to join SFC has stalled because they don't have the capacity to
> accept new projects at the moment.
> 
> We therefore applied to join SPI (http://www.spi-inc.org/), and they
> have now offered us "associated project" status
> (http://www.spi-inc.org/projects/associated-project-howto/).
> 
> We intend to accept this offer, but are taking this final opportunity to
> seek feedback from the community before doing so.
> 
> SPI is very like SFC in what it does and how it operates, so we don't
> expect this to make any substantial differences to the FAQ quoted below.
> 
> Regards,
> 
> Ganesh
> on behalf of the haskell.org committee
> 
> On 10/05/2011 23:44, Don Stewart wrote:
>> Hello everyone.
>>
>> The haskell.org committee[1], in the interest of the long-term stability
>> of the open source Haskell community infrastructure, has decided to
>> incorporate haskell.org as a legal entity. This email outlines our
>> recommendation, and seeks input from the community on this decision.
>>
>> The committee's proposal is that haskell.org incorporate as an entity
>> under the Software Freedom Conservancy umbrella organization (the same group
>> that Darcs joined recently):
>>
>> http://sfconservancy.org/
>>
>> If we proceed with this move, haskell.org will be a legal entity, and
>> registered as a non-profit, allowing us to more directly accept
>> (US tax-deductible) donations, and to invest in assets that benefit the
>> Haskell open source community.
>>
>> We welcome your feedback on the proposal attached below.
>>
>> -- Don Stewart (on behalf of the Haskell.org committee)
>>
>>
>>
>> 
>>
>> = A proposal for the incorporation of Haskell.org =
>>
>> In recent years, haskell.org has started to receive assets, e.g. money from
>> Google Summer Of Code, donations for Hackathons, and a Sparc machine for use 
>> in
>> GHC development. We have also started spending this money: in particular, on
>> hosting haskell.org itself. There is also interest in running fundraising
>> drives for specific things such as Hackathon sponsorship and hosting fees.
>>
>> However, haskell.org doesn't currently exist as a legal entity, meaning that
>> these assets have had to be held on our behalf by other entities, such as
>> Galois and various universities. This leads to tricky situations, with no-one
>> being sure who should decide how the haskell.org assets can be used.
>>
>> To solve these problems, we propose that haskell.org applies to become a 
>> member
>> project of the Software Freedom Conservancy (SFC)
>> . The SFC is a non-profit 
>> organization
>> that provides free financial and administrative services to open source
>> projects. Additionally, it has 501(c)(3) status, meaning donations from the 
>> US
>> are tax-deductible. The SFC would hold haskell.org's money and other assets,
>> and would be able to accept donations on behalf of haskell.org.
>>
>> The haskell.org committee, as described here [2], will make decisions on
>> spending assets and other decisions related to governing the non-profit.
>>
>>
>> Before proceeding, we are inviting input from the community in the form
>> of specific objections or queries regarding the plan.
>>
>> We've tried to answer some of the most likely questions:
>>
>> Q: Does this mean that my Haskell project must now be covered by a
>>  copyleft licence such as GPL?
>> A: No, but Haskell projects using haskell.org resource should use an
>> Open Source licence
>>  .
>>
>> Q: Will it still be possible to use community.h.o to host
>>  non-open-source material, such as academic papers?
>> A: An overall minority of such content, as is the current situation, is
>> not a problem.
>>
>> Q: Will it still be possible to have job ads on the haskell.org mailing
>> lists and website?
>> A: Yes.
>>
>> Q: Will this affect our ability to host the Haskell Symposium
>>   and Industrial Haskell
>> Group  webpages within haskell.org?
>> A: No.
>>
>> Q: What will be the relationship between haskell.org and other
>> organizations such as the Haskell Symposium and Industrial Haskell
>> Group?
>> A: Those organisations will continue to exist as separate entities.
>>
>> Q: If an umbrella non-profit organisation "The Haskell Foundation" was
>> created, would haskell.org be able to join it?
>> A: Yes. It's likely that in such a scenario, the Haskell Foundation
>>

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

[Ian-Woo Kim]

Hi, all,

I just uploaded hxournal-0.5.1 which is implemented with .hxournal
config file, "Use X Input" menu enabled, and a fix for compilation
problem of gdkconfig.h by Custom build during cabal configure using
"pkg-config --cflags gtk+-2.0"

Please try the new version by
> cabal update
> cabal install hxournal

I have made a google group of hxournal : hxour...@googlegroups.com
Any issues on hxournal will be welcome and discussed there.

Currently, I branched 0.5.1 version for stabilization and now started
to focus on pdf background rendering (which is most relevant for my
purpose)  in the master branch.

Thank you for your interest and reports.
best,

On Thu, Dec 15, 2011 at 4:33 PM, Edward Z. Yang  wrote:
> When I attempt to build on Ubuntu, I get:
>
> ezyang@javelin:~$ cabal install hxournal
> Resolving dependencies...
> Configuring hxournal-0.5.0.0...
> Preprocessing library hxournal-0.5.0.0...
> In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
>                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
>                 from /usr/include/gtk-2.0/gdk/gdk.h:32,
>                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
>                 from Device.hsc:3:
> /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such 
> file or directory
> compilation terminated.
> compiling dist/build/Application/HXournal/Device_hsc_make.c failed (exit code 
> 1)
> command was: /usr/bin/gcc -c 
> dist/build/Application/HXournal/Device_hsc_make.c -o 
> dist/build/Application/HXournal/Device_hsc_make.o -fno-stack-protector 
> -fno-stack-protector 
> -Wl,--hash-style=both,--no-copy-dt-needed-entries,--as-needed 
> -D__GLASGOW_HASKELL__=700 -Dlinux_BUILD_OS -Dlinux_HOST_OS -Di386_BUILD_ARCH 
> -Di386_HOST_ARCH -Icsrc -I/usr/include/glib-2.0 
> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
> -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 
> -I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/gtk-2.0 
> -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/cairo 
> -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 
> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
> -I/usr/include/cairo -I/usr/include/glib-2.0 
> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
> -I/usr/include/freetype2 -I/usr/include/libpng12 
> -I/usr/lib/ghc-7.0.3/process-1.0.1.5/include 
> -I/usr/lib/ghc-7.0.3/directory-1.1.0.0/include 
> -I/usr/lib/ghc-7.0.3/old-time-1.0.0.6/include 
> -I/usr/lib/ghc-7.0.3/unix-2.4.2.0/include 
> -I/usr/lib/ghc-7.0.3/time-1.2.0.3/include 
> -I/usr/lib/ghc-7.0.3/bytestring-0.9.1.10/include 
> -I/usr/lib/ghc-7.0.3/base-4.3.1.0/include -I/usr/lib/ghc-7.0.3/include 
> -I/usr/lib/ghc-7.0.3/include/
> cabal: Error: some packages failed to install:
> hxournal-0.5.0.0 failed during the building phase. The exception was:
> ExitFailure 1
>
> This may be of interest:
>
> ezyang@javelin:~$ locate gdkconfig.h
> /home/ezyang/Dev/gtk+/gdk/gdkconfig.h.win32
> /usr/include/gtk-3.0/gdk/gdkconfig.h
> /usr/lib/i386-linux-gnu/gtk-2.0/include/gdkconfig.h
>
> Edward
>
> Excerpts from Edward Z. Yang's message of Mon Dec 12 20:10:19 -0500 2011:
>> Very fancy! I am a big fan of Xournal, so I will have to take this for a 
>> spin.
>>
>> Edward
>>
>> Excerpts from Ian-Woo Kim's message of Mon Dec 12 06:56:09 -0500 2011:
>> > Hi, everyone,
>> >
>> > I am very pleased to announce a pen notetaking program: hxournal,
>> > which is written entirely in haskell using gtk2hs.
>> >
>> > I uploaded the package on hackage. This program accompanies with
>> > two library packages, xournal-parser and xournal-render for parsing
>> > and rendering xournal format file.
>> >
>> > http://hackage.haskell.org/package/hxournal
>> > http://hackage.haskell.org/package/xournal-parser
>> > http://hackage.haskell.org/package/xournal-render
>> >
>> > Installing hxournal should be very simple:
>> > > cabal update
>> > > cabal install hxournal
>> >
>> > hxournal can be currently regarded as a clone of xournal, which is a
>> > notetaking program developed in C. (See
>> > http://xournal.sourceforge.net)
>> >
>> > As xournal, hxournal can take wacom tablet X11 input in subpixel unit
>> > so that it can result in very smooth notetaking experience.
>> >
>> > Currently, basic pen operations and eraser operations, file open/save
>> > operations, rectangular selection, cut/copy/paste operations have been
>> > implemented. So the application is semi-usable. The file format is
>> > the same as xournal but gunzipped. So to view/edit xoj files generated
>> > from xournal, just gunzip the xoj files and read them in hxournal.
>> > Gunzipped xoj files generated from hxournal are readable in xourna

Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically

[Tom Thorne]

Hi, 

I can't remember if it was threadscope that crashed or the RTS, since I was 
also having segfaults in the RTS because of this bug, that is fixed in 7.2.2: 
http://hackage.haskell.org/trac/ghc/ticket/5552

I successfully used threadscope by running my code for fewer iterations to 
produce a smaller log, and it was helpful to make sure I was dividing work 
equally between the threads.

I think I still have the log file that was about 1.8GB so I will try running 
threadscope on it and see what happens.

The performance problems I was having turned out to be fixed completely by 
changing the GC options passed to the RTS.

thanks!

Tom 


On Friday, 16 December 2011 at 09:20, Mikolaj Konarski wrote:

> On Mon, Oct 10, 2011 at 15:55, Tom Thorne  (mailto:thomas.thorn...@gmail.com)> wrote:
> > Yes I will try to run threadscope on it, I tried it before and the event 
> > log output produced about 1.8GB, and then crashed.
> 
> 
> Hi Tom,
> 
> I'm one of the TS/ghc-events hackers and I'd like to learn more,
> fix it or at least put it on the TS/ghc-events issue tracker
> (http://trac.haskell.org/ThreadScope). Could you help me reproduce
> the problem? Did ThreadScope crash or RTS? Which versions?
> Was it 1.8GB of the log file or RAM? Did you succeed eventually?
> Any other TS feedback?
> 
> Thank you,
> Mikolaj
> 
> 


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

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

[Giovanni Tirloni]

On Fri, Dec 16, 2011 at 7:08 AM, Ganesh Sittampalam  wrote:

> > Q: If an umbrella non-profit organisation "The Haskell Foundation" was
> > created, would haskell.org be able to join it?
> > A: Yes. It's likely that in such a scenario, the Haskell Foundation
> > would become the owner of the haskell.org domain name, with the cost
> > divided between the members. The entity that is part of the SFC would
> > be renamed "community.haskell.org" in order to avoid confusion.
>

Would it be a too ambitious goal to create the "Haskell Foundation" at this
moment?

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

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

[Ganesh Sittampalam]

On 16/12/2011 10:59, Giovanni Tirloni wrote:
> On Fri, Dec 16, 2011 at 7:08 AM, Ganesh Sittampalam  > wrote:
> 
> > Q: If an umbrella non-profit organisation "The Haskell Foundation" was
> > created, would haskell.org  be able to
> join it?
> > A: Yes. It's likely that in such a scenario, the Haskell Foundation
> > would become the owner of the haskell.org 
> domain name, with the cost
> > divided between the members. The entity that is part of the
> SFC would
> > be renamed "community.haskell.org
> " in order to avoid confusion.
> 
> 
> Would it be a too ambitious goal to create the "Haskell Foundation" at
> this moment?

It would be a lot of administrative effort - managing accounts, tax
filings, etc. While it would give us more control, I don't think the
benefits would be very significant.

So in my view for now it's best not to go it alone.

Cheers,

Ganesh

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

Re: [Haskell-cafe] DB vs read/show for persisting large data

[C K Kashyap]

Thank you so much .. I am going to try out acid-state. I've been shying
away from template-haskell ... but from the looks of it,
acid-state/safecopy can do what I am looking for.
Regards,
Kashyap

On Thu, Dec 15, 2011 at 12:13 AM, Bas van Dijk  wrote:

> On 14 December 2011 15:22, Claude Heiland-Allen  wrote:
> > I ran into this very nightmare in one project, and was recommend safecopy
> > [0] by someone on the #haskell IRC channel.  I've not (yet) used it but
> it
> > looks very nice!
> >
> > [0] http://hackage.haskell.org/package/safecopy
>
> Or better yet, use acid-state which is build on top of safecopy:
>
> http://acid-state.seize.it/
>
> Bas
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Ivan Perez]

Thanks :)

It's working now. I tried it with XInput and without it. Lines seem
smoother when XInput is activated.

On 16 December 2011 11:33, Ian-Woo Kim  wrote:
> Hi, all,
>
> I just uploaded hxournal-0.5.1 which is implemented with .hxournal
> config file, "Use X Input" menu enabled, and a fix for compilation
> problem of gdkconfig.h by Custom build during cabal configure using
> "pkg-config --cflags gtk+-2.0"
>
> Please try the new version by
>> cabal update
>> cabal install hxournal
>
> I have made a google group of hxournal : hxour...@googlegroups.com
> Any issues on hxournal will be welcome and discussed there.
>
> Currently, I branched 0.5.1 version for stabilization and now started
> to focus on pdf background rendering (which is most relevant for my
> purpose)  in the master branch.
>
> Thank you for your interest and reports.
> best,
>
> On Thu, Dec 15, 2011 at 4:33 PM, Edward Z. Yang  wrote:
>> When I attempt to build on Ubuntu, I get:
>>
>> ezyang@javelin:~$ cabal install hxournal
>> Resolving dependencies...
>> Configuring hxournal-0.5.0.0...
>> Preprocessing library hxournal-0.5.0.0...
>> In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
>>                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
>>                 from /usr/include/gtk-2.0/gdk/gdk.h:32,
>>                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
>>                 from Device.hsc:3:
>> /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such 
>> file or directory
>> compilation terminated.
>> compiling dist/build/Application/HXournal/Device_hsc_make.c failed (exit 
>> code 1)
>> command was: /usr/bin/gcc -c 
>> dist/build/Application/HXournal/Device_hsc_make.c -o 
>> dist/build/Application/HXournal/Device_hsc_make.o -fno-stack-protector 
>> -fno-stack-protector 
>> -Wl,--hash-style=both,--no-copy-dt-needed-entries,--as-needed 
>> -D__GLASGOW_HASKELL__=700 -Dlinux_BUILD_OS -Dlinux_HOST_OS -Di386_BUILD_ARCH 
>> -Di386_HOST_ARCH -Icsrc -I/usr/include/glib-2.0 
>> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 
>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
>> -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 
>> -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm 
>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 
>> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
>> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 
>> -I/usr/include/libpng12 -I/usr/include/glib-2.0 
>> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/glib-2.0 
>> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/cairo 
>> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
>> -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 
>> -I/usr/lib/ghc-7.0.3/process-1.0.1.5/include 
>> -I/usr/lib/ghc-7.0.3/directory-1.1.0.0/include 
>> -I/usr/lib/ghc-7.0.3/old-time-1.0.0.6/include 
>> -I/usr/lib/ghc-7.0.3/unix-2.4.2.0/include 
>> -I/usr/lib/ghc-7.0.3/time-1.2.0.3/include 
>> -I/usr/lib/ghc-7.0.3/bytestring-0.9.1.10/include 
>> -I/usr/lib/ghc-7.0.3/base-4.3.1.0/include -I/usr/lib/ghc-7.0.3/include 
>> -I/usr/lib/ghc-7.0.3/include/
>> cabal: Error: some packages failed to install:
>> hxournal-0.5.0.0 failed during the building phase. The exception was:
>> ExitFailure 1
>>
>> This may be of interest:
>>
>> ezyang@javelin:~$ locate gdkconfig.h
>> /home/ezyang/Dev/gtk+/gdk/gdkconfig.h.win32
>> /usr/include/gtk-3.0/gdk/gdkconfig.h
>> /usr/lib/i386-linux-gnu/gtk-2.0/include/gdkconfig.h
>>
>> Edward
>>
>> Excerpts from Edward Z. Yang's message of Mon Dec 12 20:10:19 -0500 2011:
>>> Very fancy! I am a big fan of Xournal, so I will have to take this for a 
>>> spin.
>>>
>>> Edward
>>>
>>> Excerpts from Ian-Woo Kim's message of Mon Dec 12 06:56:09 -0500 2011:
>>> > Hi, everyone,
>>> >
>>> > I am very pleased to announce a pen notetaking program: hxournal,
>>> > which is written entirely in haskell using gtk2hs.
>>> >
>>> > I uploaded the package on hackage. This program accompanies with
>>> > two library packages, xournal-parser and xournal-render for parsing
>>> > and rendering xournal format file.
>>> >
>>> > http://hackage.haskell.org/package/hxournal
>>> > http://hackage.haskell.org/package/xournal-parser
>>> > http://hackage.haskell.org/package/xournal-render
>>> >
>>> > Installing hxournal should be very simple:
>>> > > cabal update
>>> > > cabal install hxournal
>>> >
>>> > hxournal can be currently regarded as a clone of xournal, which is a
>>> > notetaking program developed in C. (See
>>> > http://xournal.sourceforge.net)
>>> >
>>> > As xournal, hxournal can take wacom tablet X11 input in subpixel unit
>>> > so that it can result in very smooth notetaking experience.
>>> >
>>> > Currently, basic pen operations and eraser operations, file open/save
>>> > operations, rectangular selection, cut/copy/paste operations have been
>>> 

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

[Thomas Schilling]

On 16 December 2011 11:10, Ganesh Sittampalam  wrote:
> On 16/12/2011 10:59, Giovanni Tirloni wrote:
>> On Fri, Dec 16, 2011 at 7:08 AM, Ganesh Sittampalam > > wrote:
>>
>>     > Q: If an umbrella non-profit organisation "The Haskell Foundation" was
>>     >     created, would haskell.org  be able to
>>     join it?
>>     > A: Yes. It's likely that in such a scenario, the Haskell Foundation
>>     >     would become the owner of the haskell.org 
>>     domain name, with the cost
>>     >     divided between the members. The entity that is part of the
>>     SFC would
>>     >     be renamed "community.haskell.org
>>     " in order to avoid confusion.
>>
>>
>> Would it be a too ambitious goal to create the "Haskell Foundation" at
>> this moment?
>
> It would be a lot of administrative effort - managing accounts, tax
> filings, etc. While it would give us more control, I don't think the
> benefits would be very significant.
>
> So in my view for now it's best not to go it alone.

I agree.  If at some point we feel that having a Haskell Foundation
would be desirable (despite the additional overheads) there shouldn't
be anything stopping us from doing so.  Are there any drawbacks in
joining such an organisation?  How do they finance their overheads?
Would a donation to haskell.org include a fee to SPI?  I couldn't find
any information on their website.

/ Thomas

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

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

[Ganesh Sittampalam]

On 16/12/2011 13:21, Thomas Schilling wrote:
> On 16 December 2011 11:10, Ganesh Sittampalam  wrote:
>> On 16/12/2011 10:59, Giovanni Tirloni wrote:

>>> Would it be a too ambitious goal to create the "Haskell Foundation" at
>>> this moment?
>>
>> It would be a lot of administrative effort - managing accounts, tax
>> filings, etc. While it would give us more control, I don't think the
>> benefits would be very significant.
>>
>> So in my view for now it's best not to go it alone.
> 
> I agree.  If at some point we feel that having a Haskell Foundation
> would be desirable (despite the additional overheads) there shouldn't
> be anything stopping us from doing so.  Are there any drawbacks in
> joining such an organisation?  How do they finance their overheads?
> Would a donation to haskell.org include a fee to SPI?  I couldn't find
> any information on their website.

Yes - 5% goes to SPI to cover their overheads. It's detailed in
http://www.spi-inc.org/projects/associated-project-howto/ but not on
their donations page at http://www.spi-inc.org/donations/.

5% seems reasonable to me and in line with what similar "donation
aggregators" charge, for example the Charities Aid Foundation in the UK
charges 4%:
https://www.cafonline.org/my-personal-giving/plan-your-giving/individual-charity-account.aspx

In effect we've been getting the admin for free from Galois up till now,
but it's been getting too troublesome for them.

Cheers,

Ganesh

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

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

[Thomas Schilling]

On 16 December 2011 13:36, Ganesh Sittampalam  wrote:

>> Would a donation to haskell.org include a fee to SPI?  I couldn't find
>> any information on their website.
>
> Yes - 5% goes to SPI to cover their overheads. It's detailed in
> http://www.spi-inc.org/projects/associated-project-howto/ but not on
> their donations page at http://www.spi-inc.org/donations/.
>
> 5% seems reasonable to me and in line with what similar "donation
> aggregators" charge, for example the Charities Aid Foundation in the UK
> charges 4%:
> https://www.cafonline.org/my-personal-giving/plan-your-giving/individual-charity-account.aspx

Yes, that sounds reasonable.  Credit cards donations also cause an
overhead of 4.5% (and the 5% are deducted from the rest), so the total
overhead for a credit card donation would be: (1 - 0.955 * 0.95) =
9.3%  That's fairly high, but I don't see a way around that.

> In effect we've been getting the admin for free from Galois up till now,
> but it's been getting too troublesome for them.

Yes, I certainly understand that.  The other reason are tax-deductible
donations, which I assume isn't really possible with Galois handling
all the financials.

/ Thomas

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

Re: [Haskell-cafe] Alternative versus Monoid

[Bas van Dijk]

On 16 December 2011 05:26, Brent Yorgey  wrote:
> I, for one, would be
> quite in favor of changing the current Monoid (Maybe a) instance to
> correspond to the failure-and-prioritized-choice semantics

So lets do this. Some questions:

1) What about the First type? Do we {-# DEPRECATE #-} it?

2) What about the Last type? It could be deprecated in favor of Dual.

3) Do we need a new type (like the current Maybe) for lifting
semigroups into a Monoid? IMHO we don't since the semigroup package
does a better job with the Option type (like Brent mentioned).

4) How much code will break from this change?

5) Anyone up for proposing this to librar...@haskell.org?

Regards,

Bas

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

Re: [Haskell-cafe] Alternative versus Monoid

[Bas van Dijk]

Attached is a git patch for base which makes the proposed changes.
From 824bdca994b3fcceff21fcb68e1b18f1d4f03bd5 Mon Sep 17 00:00:00 2001
From: Bas van Dijk 
Date: Fri, 16 Dec 2011 15:16:14 +0100
Subject: [PATCH] Give the Maybe Monoid the expected
 failure-and-prioritized-choice semantics instead of the
 lift-a-semigroup-to-a-monoid semantics. The old semantics
 didn't even achieve the latter since it required a Monoid
 instance on a, rather than a semigroup Also DEPRECATE First
 in favor of Maybe and Last in favor of Dual.

---
 Data/Monoid.hs |   46 --
 1 files changed, 20 insertions(+), 26 deletions(-)

diff --git a/Data/Monoid.hs b/Data/Monoid.hs
index 228e254..d1d9564 100644
--- a/Data/Monoid.hs
+++ b/Data/Monoid.hs
@@ -186,14 +186,14 @@ instance Num a => Monoid (Product a) where
 --
 -- @
 -- findLast :: Foldable t => (a -> Bool) -> t a -> Maybe a
--- findLast pred = getLast . foldMap (\x -> if pred x
---then Last (Just x)
---else Last Nothing)
+-- findLast pred = getDual . foldMap (\x -> if pred x
+--then Dual (Just x)
+--else Dual Nothing)
 -- @
 --
 -- Much of Data.Map's interface can be implemented with
 -- Data.Map.alter. Some of the rest can be implemented with a new
--- @alterA@ function and either 'First' or 'Last':
+-- @alterA@ function and either 'Maybe' or 'Dual Maybe':
 --
 -- > alterA :: (Applicative f, Ord k) =>
 -- >   (Maybe a -> f (Maybe a)) -> k -> Map k a -> f (Map k a)
@@ -204,28 +204,21 @@ instance Num a => Monoid (Product a) where
 -- insertLookupWithKey :: Ord k => (k -> v -> v -> v) -> k -> v
 -- -> Map k v -> (Maybe v, Map k v)
 -- insertLookupWithKey combine key value =
---   Arrow.first getFirst . alterA doChange key
+--   alterA doChange key
 --   where
---   doChange Nothing = (First Nothing, Just value)
---   doChange (Just oldValue) =
--- (First (Just oldValue),
---  Just (combine key value oldValue))
+--   doChange m@Nothing = (m, Just value)
+--   doChange m@(Just oldValue) = (m, Just (combine key value oldValue))
 -- @
 
--- | Lift a semigroup into 'Maybe' forming a 'Monoid' according to
--- : \"Any semigroup @S@ may be
--- turned into a monoid simply by adjoining an element @e@ not in @S@
--- and defining @e*e = e@ and @e*s = s = s*e@ for all @s ∈ S@.\" Since
--- there is no \"Semigroup\" typeclass providing just 'mappend', we
--- use 'Monoid' instead.
-instance Monoid a => Monoid (Maybe a) where
+instance Monoid (Maybe a) where
   mempty = Nothing
-  Nothing `mappend` m = m
-  m `mappend` Nothing = m
-  Just m1 `mappend` Just m2 = Just (m1 `mappend` m2)
-
+  Nothing `mappend` r = r
+  l   `mappend` _ = l
 
 -- | Maybe monoid returning the leftmost non-Nothing value.
+--
+-- /DEPRECATED in favor of 'Maybe'!/
+{-# DEPRECATED First "Use Maybe instead" #-}
 newtype First a = First { getFirst :: Maybe a }
 #ifndef __HADDOCK__
 deriving (Eq, Ord, Read, Show)
@@ -237,11 +230,13 @@ instance Show a => Show (First a)
 #endif
 
 instance Monoid (First a) where
-mempty = First Nothing
-r@(First (Just _)) `mappend` _ = r
-First Nothing `mappend` r = r
+mempty = First mempty
+First l `mappend` First r = First (l `mappend` r)
 
 -- | Maybe monoid returning the rightmost non-Nothing value.
+--
+-- /DEPRECATED in favor of 'Dual'!/
+{-# DEPRECATED Last "Use Dual instead" #-}
 newtype Last a = Last { getLast :: Maybe a }
 #ifndef __HADDOCK__
 deriving (Eq, Ord, Read, Show)
@@ -253,9 +248,8 @@ instance Show a => Show (Last a)
 #endif
 
 instance Monoid (Last a) where
-mempty = Last Nothing
-_ `mappend` r@(Last (Just _)) = r
-r `mappend` Last Nothing = r
+mempty = Last mempty
+Last x `mappend` Last y = Last (y `mappend` x)
 
 {-
 {
-- 
1.7.5.4

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

[Haskell-cafe] Dutch national FP day, January 6, Utrecht

[S D Swierstra]

On 

http://www.cs.uu.nl/wiki/bin/view/FPDag2012/WebHome 


you will find the program and registration  information about the next Dutch 
National Functional Programming day, on January 6, Utrecht University.

Please forward this mail to anyone interested.

Any questions can be directed to me.

Hoping to meet you all,
Doaitse Swierstra




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

Re: [Haskell-cafe] Alternative versus Monoid

[Yves Parès]

 "1) What about the First type? Do we {-# DEPRECATE #-} it?"

Personnaly, I'm in favor of following the same logic than Int:
Int itself is *not *a monoid. You have to be specific: it's either Sum or
Mult.

It should be the same for Maybe: we remove its instance of Monoid, and we
only use First and Last.

2011/12/16 Bas van Dijk 

> On 16 December 2011 05:26, Brent Yorgey  wrote:
> > I, for one, would be
> > quite in favor of changing the current Monoid (Maybe a) instance to
> > correspond to the failure-and-prioritized-choice semantics
>
> So lets do this. Some questions:
>
> 1) What about the First type? Do we {-# DEPRECATE #-} it?
>
> 2) What about the Last type? It could be deprecated in favor of Dual.
>
> 3) Do we need a new type (like the current Maybe) for lifting
> semigroups into a Monoid? IMHO we don't since the semigroup package
> does a better job with the Option type (like Brent mentioned).
>
> 4) How much code will break from this change?
>
> 5) Anyone up for proposing this to librar...@haskell.org?
>
> Regards,
>
> Bas
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Alternative versus Monoid

[Yves Parès]

Sorry, I meant Sum and Product for the monoid equivalents of a Num instance.

2011/12/16 Yves Parès 

> "1) What about the First type? Do we {-# DEPRECATE #-} it?"
>
> Personnaly, I'm in favor of following the same logic than Int:
> Int itself is *not *a monoid. You have to be specific: it's either Sum or
> Mult.
>
> It should be the same for Maybe: we remove its instance of Monoid, and we
> only use First and Last.
>
>
> 2011/12/16 Bas van Dijk 
>
>> On 16 December 2011 05:26, Brent Yorgey  wrote:
>> > I, for one, would be
>> > quite in favor of changing the current Monoid (Maybe a) instance to
>> > correspond to the failure-and-prioritized-choice semantics
>>
>> So lets do this. Some questions:
>>
>> 1) What about the First type? Do we {-# DEPRECATE #-} it?
>>
>> 2) What about the Last type? It could be deprecated in favor of Dual.
>>
>> 3) Do we need a new type (like the current Maybe) for lifting
>> semigroups into a Monoid? IMHO we don't since the semigroup package
>> does a better job with the Option type (like Brent mentioned).
>>
>> 4) How much code will break from this change?
>>
>> 5) Anyone up for proposing this to librar...@haskell.org?
>>
>> Regards,
>>
>> Bas
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] What happens if you get hit by a bus?

[Michael Litchard]

I'm learning what it means to be a professional Haskell programmer,
and contemplating taking on side jobs. The path of least resistance
seems to be web applications, as that is what I do at work. I've been
investigating what some web developers have to say about their trade.
One article addresses the question above. His answer was that he uses
RoR which has a large community and he is therefore easily
replaceable. My question, for freelancers in general, and web
developers in particular is this: How do you address this question?  I
imagine potential clients would need to be assuaged of their fears
that hiring me would lead to a lock-in situation at best, and no one
to maintain a code base at worst. Lock-in won't be part of my business
model, also sooner or later we part ways with the client. When the
client wonders, "What happens then?", what is a good answer?

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Colin Adams]

I would think there were plenty of Haskell programmers ready to jump in as
replacements.

On 16 December 2011 15:37, Michael Litchard  wrote:

> I'm learning what it means to be a professional Haskell programmer,
> and contemplating taking on side jobs. The path of least resistance
> seems to be web applications, as that is what I do at work. I've been
> investigating what some web developers have to say about their trade.
> One article addresses the question above. His answer was that he uses
> RoR which has a large community and he is therefore easily
> replaceable. My question, for freelancers in general, and web
> developers in particular is this: How do you address this question?  I
> imagine potential clients would need to be assuaged of their fears
> that hiring me would lead to a lock-in situation at best, and no one
> to maintain a code base at worst. Lock-in won't be part of my business
> model, also sooner or later we part ways with the client. When the
> client wonders, "What happens then?", what is a good answer?
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Michael Litchard]

Yes! I could cite the large and growing set of libraries on hackage as evidence.

On Fri, Dec 16, 2011 at 7:40 AM, Colin Adams  wrote:
> I would think there were plenty of Haskell programmers ready to jump in as
> replacements.
>
> On 16 December 2011 15:37, Michael Litchard  wrote:
>>
>> I'm learning what it means to be a professional Haskell programmer,
>> and contemplating taking on side jobs. The path of least resistance
>> seems to be web applications, as that is what I do at work. I've been
>> investigating what some web developers have to say about their trade.
>> One article addresses the question above. His answer was that he uses
>> RoR which has a large community and he is therefore easily
>> replaceable. My question, for freelancers in general, and web
>> developers in particular is this: How do you address this question?  I
>> imagine potential clients would need to be assuaged of their fears
>> that hiring me would lead to a lock-in situation at best, and no one
>> to maintain a code base at worst. Lock-in won't be part of my business
>> model, also sooner or later we part ways with the client. When the
>> client wonders, "What happens then?", what is a good answer?
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Marc Weber]

What about just replying with this one link:
http://www.haskellers.com/

As thumb of rule it takes half the time to review code compared to
writing it (Don't remember where I read it ..).

Thus even RoR can be a lock in and delay updates if stuff changes.
The only chance is creating a team and provide services as "team".

But in the end its a matter of costs: If you have to share ideas - if
you have to keep each other up to date it'll take more time and somebody
has to pay for it in the end..

Its not only a Haskell vs RoR qusetion IMHO.

Marc Weber

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Ketil Malde]

Michael Litchard  writes:

> One article addresses the question above. His answer was that he uses
> RoR which has a large community and he is therefore easily
> replaceable. My question, for freelancers in general, and web
> developers in particular is this: How do you address this question?

In this particular case, you could argue that more people know PHP and
Python than Ruby, so surely one should avoid Ruby as well.

Managers like to think of their company as a factory, and from this
perspective, it makes sense to build your factory from easily obtainable
parts.  But the factory mindset only works when you want to manufacture
stuff, nobody who takes a minute to actually think will say that you can
replace any programmer with any other, as long as they know the same
programming language or framework.

Anyway, here's something I found interesting in that respect:

  
http://www.dachisgroup.com/2011/12/cant-get-no-satisfaction-why-service-companies-cant-keep-their-promises/

(This probably turned out less helpful than I intended, sorry :-)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

Re: [Haskell-cafe] Dutch national FP day, January 6, Utrecht

[Mathijs Kwik]

Ik wil me graag inschrijven, inc dinner.

Groeten,
Mathijs

On Fri, Dec 16, 2011 at 3:31 PM, S D Swierstra  wrote:
> On
>
> http://www.cs.uu.nl/wiki/bin/view/FPDag2012/WebHome
>
>
> you will find the program and registration  information about the next Dutch 
> National Functional Programming day, on January 6, Utrecht University.
>
> Please forward this mail to anyone interested.
>
> Any questions can be directed to me.
>
> Hoping to meet you all,
> Doaitse Swierstra
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Brian Hurt]

I think the "truck-factor" implications of the programming language as
dwarfed by the implications of everything else in the project.  Any project
of any significant size is going to have a huge amount of project-specific
information tucked up inside the programmers head.  It doesn't matter if
there are a million other programmers who know the language you used, or
only a dozen- if you're the only one who knows how things were done, and
more importantly, why they were done that way, and you get hit by a truck,
then your boss has a big problem.  Whether there are millions of candidate
replacement programmers, or only dozens, none of them had the
project-specific knowledge you had.  Finding a replacement who knows the
language is the least of his problems.

On Fri, Dec 16, 2011 at 10:40 AM, Colin Adams wrote:

> I would think there were plenty of Haskell programmers ready to jump in as
> replacements.
>
> On 16 December 2011 15:37, Michael Litchard  wrote:
>
>> I'm learning what it means to be a professional Haskell programmer,
>> and contemplating taking on side jobs. The path of least resistance
>> seems to be web applications, as that is what I do at work. I've been
>> investigating what some web developers have to say about their trade.
>> One article addresses the question above. His answer was that he uses
>> RoR which has a large community and he is therefore easily
>> replaceable. My question, for freelancers in general, and web
>> developers in particular is this: How do you address this question?  I
>> imagine potential clients would need to be assuaged of their fears
>> that hiring me would lead to a lock-in situation at best, and no one
>> to maintain a code base at worst. Lock-in won't be part of my business
>> model, also sooner or later we part ways with the client. When the
>> client wonders, "What happens then?", what is a good answer?
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Steve Schafer]

On Fri, 16 Dec 2011 11:17:20 -0500, Brian Hurt  wrote:

>I think the "truck-factor" implications of the programming language as
>dwarfed by the implications of everything else in the project.  Any project
>of any significant size is going to have a huge amount of project-specific
>information tucked up inside the programmers head.  It doesn't matter if
>there are a million other programmers who know the language you used, or
>only a dozen- if you're the only one who knows how things were done, and
>more importantly, why they were done that way, and you get hit by a truck,
>then your boss has a big problem.  Whether there are millions of candidate
>replacement programmers, or only dozens, none of them had the
>project-specific knowledge you had.  Finding a replacement who knows the
>language is the least of his problems.

I believe that you're absolutely right. I also believe that corporate
decision makers rarely, if ever, think that way. And that's the problem:
You have to deal with the perception, not the reality.

So, that's the real question that needs to be answered: How do you deal
with the _perception_ that hiring a Haskell developer instead of a
Rails, etc. developer will result in more chaos when said developer is
hit by a bus?

-Steve Schafer

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Ivan Perez]

Just like Michael, I've been learning what it means to be a professional
Haskell programmer for a few months.

I think the case of Ruby on Rails and Haskell are very, very, very different.

Ruby on Rails has been around for many years. There are books, tutorials,
examples, websites, etc. Still, there are not as many developers that use
Rails than those that use PHP, or Java, or .NET, or Python (for web
development). But there are many.

This is definitely not the case with Haskell. If you go around the internet,
it's not just that you can't find Haskell programmers with the necessary skills.
You also cannot find people demanding these jobs, servers that support
Haskell for web, or success stories to convince others and yourself that this
is the right platform for this job.

After several months, I just found the first client for which I'll
create a website
using Yesod.

Being a professional Haskell developer requires many skills that have nothing
to do with Haskell. Unless you are born with the talent of having the tax rules
embedded in your head, you'll have to learn them. Maybe the hard way. That is
true for lots of tasks related to social skills, design, management,
negotiation.
such as "how do I know what the client really wants without wasting
hundreds of hours", "how the heck do I show my client what I have in mind"
or "should this button go on the right or on the left and why should I care".

Learning them takes time, and most of us don't learn them unless we actually
need to. It's not that there aren't any people capable of creating
websites using Haskell, or Haskell programmers who could learn to do it.

It's just that not many people know enough, as of this day, to deliver
a professional
product with the results that clients expect.

In my experience, the following help:

 - Have a good portfolio, a list of websites you've created in Haskell
that shows they
have nothing to fear. If you can't find clients, create websites for
free. Sparked.com
may help. You'll know the list is good when there are great jobs that
you choose not
to include in it.

 - Ask your previous clients and those you created websites for to
leave feedback,
acknowledge your work publicly or recommend you on linkedin.

- Make a list of your competitors names and addresses (and put my name
on top of the list ;)
Haskellers.org may help. So can linkedin, guru.com, peopleperhour,
etc. If they ask, tell them
that there are tens of programmers with the necessary experience to go
on if they are not
satisfied with your work. If you want, we can created a group in a
social network just
for this, with the requirement that you must have created an actual
product to be in the group.

The amount of packages in hackage means Nothing to me. It means
nothing to my clients.

Good luck.

Cheers,
Ivan

On 16 December 2011 17:08, Ketil Malde  wrote:
> Michael Litchard  writes:
>
>> One article addresses the question above. His answer was that he uses
>> RoR which has a large community and he is therefore easily
>> replaceable. My question, for freelancers in general, and web
>> developers in particular is this: How do you address this question?
>
> In this particular case, you could argue that more people know PHP and
> Python than Ruby, so surely one should avoid Ruby as well.
>
> Managers like to think of their company as a factory, and from this
> perspective, it makes sense to build your factory from easily obtainable
> parts.  But the factory mindset only works when you want to manufacture
> stuff, nobody who takes a minute to actually think will say that you can
> replace any programmer with any other, as long as they know the same
> programming language or framework.
>
> Anyway, here's something I found interesting in that respect:
>
>  http://www.dachisgroup.com/2011/12/cant-get-no-satisfaction-why-service-companies-cant-keep-their-promises/
>
> (This probably turned out less helpful than I intended, sorry :-)
>
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

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

[Niklas Broberg]

On Thu, Dec 15, 2011 at 5:33 PM, Sean Leather  wrote:

> On Thu, Dec 15, 2011 at 11:07, Niklas Broberg wrote:
>
>> Envisioned: The function you ask for can definitely be written for
>> haskell-src-exts, which I know you are currently using. I just need to
>> complete my type checker for haskell-src-exts first. Which is not a small
>> task, but one that has been started.
>
>
> That's good to know! I presume it's something like Haskell98 to start
> with? I'd be even more impressed (and possibly also concerned for your
> health) if you were going to tackle all of the extensions!
>

Actually, no. Starting with Haskell98 would just lead to great pains later
on, since many of the extensions require very invasive changes compared to
a H98 checker. My starting point has been to identify the core structural
and algorithmical requirements for a type checker that would indeed tackle
"all" of the extensions.

My current checker (which I wouldn't even call half-complete) is based on a
merge of the algorithms discussed in [1] and [2]. Between the two, they
give, on the one hand, the bidirectional inference needed to handle
arbitrary-rank types, and, on the other hand, the power of local
assumptions needed to handle GADTs and type families.

I thank you for your concerns for my health. However, I assure you they are
quite misplaced. Typing Haskell-with-extensions in Haskell is not only a
far smaller beast than what it's made out to be, when walking in the
well-documented footsteps of giants. It is also lots of fun. :-)


> I've been trying to find a student to write a haskell-src-exts type
> checker for me. It should use a particular kind of mechanism though, using
> constraints similar to [1]. Then, I want to adapt that to do
> transformations. What approach are you using? Maybe I can somehow steal
> your work... ;)
>

As you note from my starting references, I'm using the same approach and
base algorithms as GHC does. I looked at some alternatives briefly,
including the work you reference, but I discarded them all since none of
them had support for everything I wanted to cover. In particular, it is not
at all clear how these systems would merge with bi-directional inference or
local assumptions. Tackling *that* problem would be a large and very
interesting research topic I'm sure, but not one I have time to dig into at
the current time. Indeed, the feasibility of my project (and thus the
sanctity of my health) relies very heavily on the "footsteps-of-giants"
factor...

So as not to give anyone false hopes, I should point out that I currently
have next to no time at all to devote to this, and the project has been
dormant since August. I'll return to it for sure, but at the moment cannot
tell when.

Cheers,

/Niklas

[1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical
type inference for arbitrary-rank types.
[2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann.
OutsideIn(X) – Modular type inference with local assumptions
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Niklas Broberg]

On Thu, Dec 15, 2011 at 6:24 PM, Thomas Schilling
wrote:

> What exactly are the hopes for such a type checker?  I can understand
> it being interesting as a research project, but as a realistic tools
> there are two huge issues:
>
>  1. It's going to take a LOT of time to reach feature parity with
> GHC's type checker.
>
>  2. Assuming that can be done, how is it going to be maintained and
> kept up to date with GHC?
>
> If it is going to be used as a development tool, both of these are a
> major requirement.  I haven't looked into the issues, but I'd expect
> it would be more realistic (although definitely not trivial) to
> translate from GHC's internal AST into an annotated haskell-src-exts
> AST.
>

With all due respect, the sentiments you give voice to here are a large
part of what drives me to do this project in the first place. Haskell is
not GHC, and I think that the very dominant position of GHC many times
leads to ill thought-through extensions. Since GHC has no competitor, often
extensions (meaning behavior as denoted and delimited by some -X flag) are
based on what is most convenient from the implementation point of view,
rather than what would give the most consistent, logical and modular user
experience (not to mention
third-party-tool-implementor-trying-to-support-GHC-extensions experience).

As such, I'm not primarily doing this project to get a development tool
out, even if that certainly is a very neat thing. I'm just as much doing it
to provide a Haskell (front-end) implementation that can serve as a better
reference than GHC, one that very explicitly does *not* choose the
convenient route to what constitutes an extension, and instead attempts to
apply rigid consistency and modularity between extensions. Also, just like
for haskell-src-exts I hope to build the type checker from the roots with
the user interface as a core design goal, not as a tacked-on afterthought.

Mind you, in no way do I intend any major criticism towards GHC or its
implementors. GHC is a truly amazing piece of software, indeed it's
probably my personal favorite piece of software of all times. That does not
mean it comes free of quirks and shady corners though, and it is my hope
that by doing what I do I can help shine a light on them.

Answering your specific issues:

1) Yes, it's a lot of work. Probably not half as much as you'd think
though, see my previous mail about walking in the footsteps of giants. But
beyond that, I think it's work that truly needs to be done, for the greater
good of Haskell.

2) Well, I think I've done a reasonably good job keeping haskell-src-exts
up to date so far, even if the last year has been pretty bad in that regard
(writing a PhD thesis will do that to you). I'll keep doing it for the type
checker as well. But I am but one man, so if anyone else feels like joining
the project then they are more than welcome to.

Sort-of-3) Yes, both implementation and maintenance are likely going to be
far more costly than the alternative to do a translation via the GHC API.
I'm not interested in that alternative though.

Cheers,

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Yves Parès]

Tell them that if you were instead on Rails, you'd have a huge chance of
being hit by a train, which is likely to deal far more damage than a bus.

2011/12/16 Michael Litchard 

> I'm learning what it means to be a professional Haskell programmer,
> and contemplating taking on side jobs. The path of least resistance
> seems to be web applications, as that is what I do at work. I've been
> investigating what some web developers have to say about their trade.
> One article addresses the question above. His answer was that he uses
> RoR which has a large community and he is therefore easily
> replaceable. My question, for freelancers in general, and web
> developers in particular is this: How do you address this question?  I
> imagine potential clients would need to be assuaged of their fears
> that hiring me would lead to a lock-in situation at best, and no one
> to maintain a code base at worst. Lock-in won't be part of my business
> model, also sooner or later we part ways with the client. When the
> client wonders, "What happens then?", what is a good answer?
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Bardur Arantsson]

Michael Litchard wrote:

[--snip--]

If getting hit by a bus is a significant factor in the overall outcome of 
the project then I think those are pretty good odds, aren't they?

(I do realize that traffic accidents are a lot more frequent than we like to 
think, but still...)

-- 
Bárður Árantsson



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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Andrew Coppin]

On 16/12/2011 07:05 PM, Bardur Arantsson wrote:

Michael Litchard wrote:

[--snip--]

If getting hit by a bus is a significant factor in the overall outcome of
the project then I think those are pretty good odds, aren't they?

(I do realize that traffic accidents are a lot more frequent than we like to
think, but still...)


The /actual/ probability of being hit by a bus is irrelevant. The only 
thing of concequence is the /percieved/ probability. This latter 
quantity is not related to the former in any meaningful way. In fact, 
due to an effect known as availability bias, the probability of any 
potential threat varies depending on how long you spend thinking about it.


(In other words, if you've never even considered what would happen if 
your sole developer got hit by a bus, your estimate of the probability 
of this will be very low. If you sit down and think about how much 
trouble you'd be in if this actually happened, suddenly your estimate of 
the probability starts increasing. This is completely illogical - which 
is why it's called a cognitive bias.)


Ever heard the phrase "fear, uncertainty and doubt"? It's a killer in a 
business context.


It seems clear [to me] that there are actually quite a few Haskell 
programmers around, and it's not especially hard to find them. The 
question is how many "good" ones there are. "Good" is all vague and 
subjective and hard to measure, unfortunately.


On the other hand, if you just start the project with more than one 
developer on board in the first place, then the possibility of just one 
of them being killed prematurely becomes drastically less serious. (For 
the business. I'm sure it's still fairly serious for the person who just 
DIED...)


PS. Kudos to Ketil Malde for the best link I've seen today.

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Brian Hurt]

On Fri, Dec 16, 2011 at 3:51 PM, Andrew Coppin
wrote:

> On 16/12/2011 07:05 PM, Bardur Arantsson wrote:
>
>> Michael Litchard wrote:
>>
>> [--snip--]
>>
>> If getting hit by a bus is a significant factor in the overall outcome of
>> the project then I think those are pretty good odds, aren't they?
>>
>> (I do realize that traffic accidents are a lot more frequent than we like
>> to
>> think, but still...)
>>
>
> The /actual/ probability of being hit by a bus is irrelevant. The only
> thing of concequence is the /percieved/ probability. This latter quantity
> is not related to the former in any meaningful way. In fact, due to an
> effect known as availability bias, the probability of any potential threat
> varies depending on how long you spend thinking about it.
>
> (In other words, if you've never even considered what would happen if your
> sole developer got hit by a bus, your estimate of the probability of this
> will be very low. If you sit down and think about how much trouble you'd be
> in if this actually happened, suddenly your estimate of the probability
> starts increasing. This is completely illogical - which is why it's called
> a cognitive bias.


There are a lot of ways that, from the perspective of the business, a
person could get "hit by a bus"- they could get into an accident, including
getting hit by a bus, die for some other reason, get sick, retire, get
another job, or even quit to join the Peace Corp and get shipped off to
Uganda (actually had that happen to me once).  Sooner or later, everyone
will be metaphorically "hit by a bus", in that they will not be here
anymore.  Next time this discussion comes up, as the room how many people
have been at their company for 20 years or more.  Then ask them to guess
how many people in the room will still be at the company in 20 years time.
 The high probability is that very few, if any, people will still be at the
company in 20 years time.

It doesn't matter why Bob is no longer here with his specialized knowledge
of Bob's code, but the end result is the same.  And the problem is the
same- someone else has to be brought in to deal with Bob's code.  And that
someone, even if they know the language the code is written in as well, or
even better, than Bob, doesn't know the *code*.  And it's just a question
of when, not if, Bob will no longer be there to maintain the code.

If anything, using Haskell *reduces* the truck-factor compared to other
languages.  Someone new coming in needs to be able to make small changes
fairly quickly (major reorganizations and refactorings can generally be
delayed while the new person comes up to speed, but small bug fix and small
feature additions are a constant need).  What Nancy the new hire can do, if
the code is in Haskell, is simply change the function, and let the compiler
figure out where it's being used.  Also, types are a wonderful bit of
documentation- see the paper "Theorems for Free" by Phillip Wadler.  This
makes it easier fo the new person to come up to speed on what the code
does, if not necessarily how or why.


>
> Ever heard the phrase "fear, uncertainty and doubt"? It's a killer in a
> business context.
>
> It seems clear [to me] that there are actually quite a few Haskell
> programmers around, and it's not especially hard to find them. The question
> is how many "good" ones there are. "Good" is all vague and subjective and
> hard to measure, unfortunately.
>
> On the other hand, if you just start the project with more than one
> developer on board in the first place, then the possibility of just one of
> them being killed prematurely becomes drastically less serious. (For the
> business. I'm sure it's still fairly serious for the person who just
> DIED...)
>
>
Again, it depends.  If there was this large body of code that only one
developer ever worked on, then you have truck-factor problems.



> PS. Kudos to Ketil Malde for the best link I've seen today.
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>

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

Re: [Haskell-cafe] What happens if you get hit by a bus?

[Bardur Arantsson]

Andrew Coppin wrote:

> On 16/12/2011 07:05 PM, Bardur Arantsson wrote:
>> Michael Litchard wrote:
>>
>> [--snip--]
>>
>> If getting hit by a bus is a significant factor in the overall outcome of
>> the project then I think those are pretty good odds, aren't they?
>>
>> (I do realize that traffic accidents are a lot more frequent than we like
>> to think, but still...)
> 
> The /actual/ probability of being hit by a bus is irrelevant. The only
> thing of concequence is the /percieved/ probability. This latter
> quantity is not related to the former in any meaningful way. In fact,
> due to an effect known as availability bias, the probability of any
> potential threat varies dependi
> ng on how long you spend thinking about it.

[snip blah blah blah]

- Not to be rude, but... (*)

That was the point of my post.

If you're actually confronted with this perception that traffic accidents 
are relevant to project success, you're already in deep manure because 
there's so much more than code in a project. That's what you need to 
explain.

Code is the "means" of getting us to an "end". It seems these people are 
worring about the "means" when the big problem is actually conveying the 
"ends".

(Again, just my take on the situation, I'm not claiming canonicity or 
anything.)

-- 
Bárður Árantsson

(*) I realize that this is rude. I can only apologize.


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

[Haskell-cafe] I've just heard of a neat security measure that when you compile the code it generates different object code...

[KC]

... with the same functionality.

Thus, your program would be a moving target to hackers.

Would this be challenging with ghc?

-- 
--
Regards,
KC

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

Re: [Haskell-cafe] I've just heard of a neat security measure that when you compile the code it generates different object code...

[Chris Wong]

On Sat, Dec 17, 2011 at 12:27 PM, KC  wrote:
> ... with the same functionality.
>
> Thus, your program would be a moving target to hackers.
>
> Would this be challenging with ghc?

Although it's possible, I doubt this would do anything. Most exploits
are just programmer mistakes; changing the object code doesn't change
the fact that there's a gaping security hole in your program. Plus, it
would be harder to debug the compiler, since the mangling code would
be non-deterministic by definition. So I doubt anyone would try to
implement that.

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

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

[Thomas Schilling]

On 16 December 2011 17:44, Niklas Broberg  wrote:
> With all due respect, the sentiments you give voice to here are a large part
> of what drives me to do this project in the first place. Haskell is not GHC,
> and I think that the very dominant position of GHC many times leads to ill
> thought-through extensions. Since GHC has no competitor, often extensions
> (meaning behavior as denoted and delimited by some -X flag) are based on
> what is most convenient from the implementation point of view, rather than
> what would give the most consistent, logical and modular user experience
> (not to mention
> third-party-tool-implementor-trying-to-support-GHC-extensions experience).

I agree.  Various record proposals have been rejected because of the
"not easily implementable in GHC" constraint.  Of course, ease of
implementation (and maintenance) is a valid argument, but it has an
unusual weight if GHC is the (in practise) only implementation.  Other
extensions seem to just get added on (what feels like) a whim (e.g.,
RecordPuns).

> As such, I'm not primarily doing this project to get a development tool out,
> even if that certainly is a very neat thing. I'm just as much doing it to
> provide a Haskell (front-end) implementation that can serve as a better
> reference than GHC, one that very explicitly does *not* choose the
> convenient route to what constitutes an extension, and instead attempts to
> apply rigid consistency and modularity between extensions. Also, just like
> for haskell-src-exts I hope to build the type checker from the roots with
> the user interface as a core design goal, not as a tacked-on afterthought.
>
> Mind you, in no way do I intend any major criticism towards GHC or its
> implementors. GHC is a truly amazing piece of software, indeed it's probably
> my personal favorite piece of software of all times. That does not mean it
> comes free of quirks and shady corners though, and it is my hope that by
> doing what I do I can help shine a light on them.

Wll... I've gotten a little bit of a different perspective on this
since working at a company with very high code quality standards (at
least for new code).  There is practically no observable code review
happening.  I'm sure Dimitrios and Simon PJ review most of each
other's code every now and then, but overall there is very little code
review happening (and no formal, recorded code review whatsoever).
Cleaning up the GHC code base is a huge task -- it uses lots of dirty
tricks (global variables, hash tables, unique generation is
non-deterministic, ...) which often complicate efforts tremendously (I
tried).  The lack of a unit tests doesn't help (just rewriting code so
that it can be tested would help quite a bit).

Don't get me wrong, I certainly appreciate the work the GHC team is
doing, but GHC strikes a fine balance between industrial needs and
research needs.  I'm just wondering whether the balance is always
right.

> Answering your specific issues:
>
> 1) Yes, it's a lot of work. Probably not half as much as you'd think though,
> see my previous mail about walking in the footsteps of giants. But beyond
> that, I think it's work that truly needs to be done, for the greater good of
> Haskell.

Right OutsideIn(X) (the Journal paper description, not the ICFP'09
version) seems like the right way to go.  I wasn't aware of the other
paper (the original work on bidirectional type inference seemed very
unpredictable in terms of when type annotations are needed, so I'm
looking forward to how this new paper handles things).

> 2) Well, I think I've done a reasonably good job keeping haskell-src-exts up
> to date so far, even if the last year has been pretty bad in that regard
> (writing a PhD thesis will do that to you). I'll keep doing it for the type
> checker as well. But I am but one man, so if anyone else feels like joining
> the project then they are more than welcome to.
>
> Sort-of-3) Yes, both implementation and maintenance are likely going to be
> far more costly than the alternative to do a translation via the GHC API.
> I'm not interested in that alternative though.

Fair enough.  As I am interested in building reliable (and
maintainable) development tools my priorities are obviously different.
 For that purpose, using two different implementations can lead to
very confusing issues for the user (that's why I was asking about bug
compatibility).  Apart from the bus factor, there is also the
bitrotting issue due to GHC's high velocity.  For example, even though
HaRe does build again it doesn't support many commonly used GHC
extensions and it is difficult to add them into the existing code base
(which isn't pretty).

Anyway, good luck with your endeavours.

/ Thomas
-- 
Push the envelope. Watch it bend.

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

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

[Matthew Farkas-Dyck]

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

(1) If we do (4), then the documentation ought to be adequate as-is.
(2) In my opinion, no. If one is writing code polymorphic in
(Alternative f => f), then one needn't worry. If one is using such
code, then one ought to know whether some and many are sane for the
types in question, anyhow (O_ō)
(4) This is very reasonable; not the least solutions, but hey, they
converge (^_^)

> Cheers,
> Greg

Cheers,
Matthew Farkas-Dyck

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

Re: [Haskell-cafe] Alternative versus Monoid

[Matthew Farkas-Dyck]

On 15/12/2011, Conor McBride  wrote:
>
> On 15 Dec 2011, at 15:19, Brent Yorgey wrote:
>
>> On Thu, Dec 15, 2011 at 06:49:13PM +1000, Gregory Crosswhite wrote:
>>>
>>> So at the end of the day... what is the point of even making Maybe
>>> and [] instances of Alternative?
>>
>> The Alternative and Monoid instances for [] are equivalent.  However,
>> the Alternative and Monoid instances for Maybe are not. To wit:
>>
>>> (Just (Sum  4)) <|> (Just (Sum 3))
>>  Just (Sum {getSum = 4})
>>
>>> (Just (Sum 4)) `mappend` (Just (Sum 3))
>>  Just (Sum {getSum = 7})
>
> The current monoid instance for Maybe is, in my view, unfortunate.
>
> Types are about semantic purpose, not just data representation.
> Many purposes can be represented in the same way. We should identify
> the purpose of a type (or type constructor), then define instances
> consistent with that purpose. And better, we acquire by instance
> inference compound instances consistent with that purpose! (A similar
> view is often articulated well by Conal Elliott. But perhaps it's
> just a "Con" thing.)
>
> The purpose of Maybe, it seems to me, is to model failure and
> prioritized choice, after the manner of exceptions. It's clear
> what the failure-and-prioritized-choice monoid is.
>
> It so happens that the same data representation can be used to make
> a semigroup into a monoid by attaching an identity element. That's
> a different semantic purpose, which deserves a different type.
>
> This really bites. I really like being able to write things like
>
>newtype P a x = P ([a] -> Maybe (x, [a])) deriving Monoid
>
> and then make MonadPlus/Alternative instances just by copying the
> monoid that results, but it doesn't work!
>
> It's unfortunate that we don't have local quantification in
> constraints, so we can't write (forall x. Monoid (f x)), hence the
> need for constructor classes doing basically the same job, with,
> of necessity, newly renamed members. I think it compounds the
> problem to choose inconsistent behaviour between the constructor
> class and the underlying type class.
>
> Maybe I'm an extremist, but I'd prefer it if every Alternative
> instance was constructed by duplicating a polymorphic Monoid
> instance.
>
> Meanwhile, as for the issue which kicked this off, I do think it's
> good to document and enforce meaningful (i.e. total on total input)
> usages of operations by types where practical. At present, refining
> one type class into several to account for subtle issues (like
> whether some/many actually work) is expensive, even if it's
> desirable. I'd once again plug default superclass instances and
> Control.Newtype, then suggest that the library might benefit from a
> little pruning.
>
> All the best
>
> Conor
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

By my reason, the instance (Monoid a => Monoid (Maybe a)) is
appropriate, since we have another class for inner-type-agnostic
choice -- Alternative! (and MonadPlus, but that's essentially the
same, and would be if (Functor m => Applicative m => Monad m), as it
ought).

Cheers,
Matthew Farkas-Dyck

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

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

[Gregory Crosswhite]

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

> (1) If we do (4), then the documentation ought to be adequate as-is.

I see your point that if we do (4) then some and many are no longer problematic 
for Maybe and [], and thus we don't need warnings for those types.  However, 
nonetheless we will *still* need *big warnings* *for the sake of others who 
write Alternative instances* for new types to make sure that these instances do 
not fall into the same trap as Maybe and [].  That is, we want to let future 
authors of instances know about the conditions under which they will need to 
write their own versions of some and maybe in order to make sure that these 
methods have sensible behavior.

In addition to this, we also really need some additional documentation 
explaining what the point of some and many are, since few people have any clue 
about them.  :-)

Finally, if we adopt (4) then we will need to change the documentation to 
remove "least" from "least solutions of the equations" since the phrase will no 
longer be correct.  Better still, we could replace the phrase entirely with 
something like "least *converging* solutions of the equations". (*)

Cheers,
Greg

(*) P.S:

Dear people who are better at this kind of technical language than I:

I am fully aware of the fact that the phrase "least converging solutions of the 
equations [...]" is sloppy wording at best and absolutely wrong at worst, but 
hopefully you should at least understand what I am *trying* to get at.  Thus, I 
would welcome either your feedback on what it is that I am supposed to be 
thinking and saying, or an explanation about why the idea I am trying to 
conceive and convey is so intrinsically poorly formed that I am best off just 
giving up on it.  ;-)___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Alternative versus Monoid

[Gregory Crosswhite]

On Dec 17, 2011, at 1:26 AM, Yves Parès wrote:

> "1) What about the First type? Do we {-# DEPRECATE #-} it?"
> 
> Personnaly, I'm in favor of following the same logic than Int:
> Int itself is not a monoid. You have to be specific: it's either Sum or Mult.
> 
> It should be the same for Maybe: we remove its instance of Monoid, and we 
> only use First and Last.

+1 for this idea, because it follows the principle of least surprise.

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

Re: [Haskell-cafe] Alternative versus Monoid

[Gregory Crosswhite]

On Dec 17, 2011, at 1:26 AM, Yves Parès wrote:

> "1) What about the First type? Do we {-# DEPRECATE #-} it?"
> 
> Personnaly, I'm in favor of following the same logic than Int:
> Int itself is not a monoid. You have to be specific: it's either Sum or Mult.
> 
> It should be the same for Maybe: we remove its instance of Monoid, and we 
> only use First and Last.


+1 for this idea, because it follows the principle of least surprise.

Cheers,
Greg

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

Re: [Haskell-cafe] Alternative versus Monoid

[Gregory Crosswhite]

On Dec 17, 2011, at 12:51 PM, Matthew Farkas-Dyck wrote:

> By my reason, the instance (Monoid a => Monoid (Maybe a)) is
> appropriate, since we have another class for inner-type-agnostic
> choice -- Alternative! (and MonadPlus, but that's essentially the
> same, and would be if (Functor m => Applicative m => Monad m), as it
> ought).

Yes, but the problem here is that having different behavior for Alternative, 
MonadPlus, and Monoid instances is inherently confusing, in the sense that this 
would almost certainly surprise someone who wasn't already aware of the 
difference between the instances.

Regardless, even if we keep the current behavior, we *really* *really* need to 
improve the documentation for the Monoid instance of Maybe.  Currently it reads:

 "Lift a semigroup into Maybe forming a Monoid according to 
http://en.wikipedia.org/wiki/Monoid: "Any semigroup S may be turned into a 
monoid simply by adjoining an element e not in S and defining e*e = eand e*s = 
s = s*e for all s  S." Since there is no "Semigroup" typeclass providing just 
mappend, we use Monoid instead."

Now, I just happened to have recently spent time studying the properties of 
Semigroups and Monoids, so this explanation made perfect sense to me and was a 
beautiful way of explaining what is going on.  A typical user, however --- 
which would have included me roughly one month ago :-) --- would have looked at 
this and just seen goobledegook which reinforced their perception that Haskell 
is first and foremost a playground for mathematicians.  It would be much, much 
better for the documentation to be something like this:



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

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

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



Incidentally, would people be interested in me sending a patch to update the 
documentation to be more along these lines?  (After applying your feedback, of 
course!)  If so, could you point me to where I could learn about the process 
for doing so?

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

Re: [Haskell-cafe] Alternative versus Monoid

[Gregory Crosswhite]

On Dec 17, 2011, at 2:57 PM, Gregory Crosswhite wrote:

> +1 for this idea, because it follows the principle of least surprise.

Sorry about the double-post!  I was foolish enough not only to use 
unsafePerformIO to send my e-mail, but to forgot to mark the sending routine 
with NOINLINE pragma.  As a result, the sending action was sparked and run 
twice by the runtime environment.

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

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

[Gregory Crosswhite]

On Dec 17, 2011, at 9:58 AM, Thomas Schilling wrote:

> Wll... I've gotten a little bit of a different perspective on this
> since working at a company with very high code quality standards (at
> least for new code).  There is practically no observable code review
> happening.  I'm sure Dimitrios and Simon PJ review most of each
> other's code every now and then, but overall there is very little code
> review happening (and no formal, recorded code review whatsoever).
> Cleaning up the GHC code base is a huge task -- it uses lots of dirty
> tricks (global variables, hash tables, unique generation is
> non-deterministic, ...) which often complicate efforts tremendously (I
> tried).  The lack of a unit tests doesn't help (just rewriting code so
> that it can be tested would help quite a bit).

So in other words, would it be helpful it we recruited GHC janitors?  That is, 
similar to how we have the Trac which gives people bug reports to pick out and 
work on, would it make sense to have a Trac or some other process which gives 
people chunks of code to clean up and/or make easier to test?

(I am of course inspired in suggesting this by the Linux kernel janitors, 
though it doesn't look like the project has survived, and maybe that portends 
ill for trying to do the same for GHC...)

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