Arch Haskell News: Nov 23 2008

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Arch Haskell News: Nov 23 2008

Don Stewart-2
News about Haskell on Arch Linux

    * Arch now has 734 Haskell packages now
    * That’s an increase of 29 new packages in the last 8 days!
    * 3.6 new Haskell releases are occuring each day.

Noteworthy,
           
    * haskell-hledger-0.2: “A ledger-compatible text-based accounting tool.”
    * gitit-0.3.1: “Wiki using HAppS, git, and pandoc.”
    * lhc-20081121: “Lhc Haskell Compiler”
    * haskell-hosc-0.6: “Haskell Open Sound Control”
    * haskell-flickr-0.3.2: “Haskell binding to the Flickr API”
    * haskell-delicious-0.3.2: “Accessing the del.icio.us APIs from Haskell (v2)”
    * haskell-mediawiki 0.2.3: “Interfacing with the MediaWiki API”
    * darcs-2.1.2.2: “a distributed, interactive, smart revision control system”

Full update list,

    http://archhaskell.wordpress.com/2008/11/24/arch-haskell-news-nov-23-2008/

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Compilers

Andrew Coppin
Don Stewart wrote:
> Noteworthy,
>            
>     * lhc-20081121: “Lhc Haskell Compiler”
>  

Interesting. I can't find out any information about this...

 From time to time you do hear about Haskell compilers that aren't GHC,
but I'm not aware of any other compilers that are production-grade yet.
Has anybody ever made one? (Hugs is the only one I know of...)

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Jake Mcarthur-2
Andrew Coppin wrote:
> Don Stewart wrote:
>> Noteworthy,
>>                * lhc-20081121: “Lhc Haskell Compiler”
>>  
>
> Interesting. I can't find out any information about this...

It is a fork of the JHC compiler, which should be easier to look up.
There is also Hugs, as you mentioned. In addition, you may want to look
at YHC and NHC.

- Jake


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (268 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Donnie Jones
In reply to this post by Andrew Coppin
Hello Andrew,

On Wed, Nov 26, 2008 at 4:24 PM, Andrew Coppin <[hidden email]> wrote:
Don Stewart wrote:
Noteworthy,
             * lhc-20081121: "Lhc Haskell Compiler"
 

Interesting. I can't find out any information about this...


Here is the current homepage for the LHC project:
  http://lhc.seize.it/

Hope that helps.
__
Donnie Jones


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Andrew Coppin
In reply to this post by Jake Mcarthur-2
Jake McArthur wrote:

> Andrew Coppin wrote:
>> Don Stewart wrote:
>>> Noteworthy,
>>>                * lhc-20081121: “Lhc Haskell Compiler”
>>>  
>>
>> Interesting. I can't find out any information about this...
>
> It is a fork of the JHC compiler, which should be easier to look up.
> There is also Hugs, as you mentioned. In addition, you may want to
> look at YHC and NHC.

Yeah, the "implementations" page on the Wiki basically says that there's
GHC and Hugs, and there's also these things called YHC, NHC and JHC. All
the documentation I've read makes these latter compilers sound highly
experimental and unusable. (I don't recall specifically which of them,
but I remember hearing it can't even compile the Prelude yet.) They seem
like small projects which are probably interesting to hack with, but not
much use if you're trying to produce production-grade compiled code to
give to a customer...

OTOH, I haven't ever attempted to *use* any of these compilers. I only
read about them...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Andrew Coppin
In reply to this post by Donnie Jones
Donnie Jones wrote:
>
> Here is the current homepage for the LHC project:
>   http://lhc.seize.it/
>
> Hope that helps.

Yes. I found that - it just didn't *say* very much. ;-)

I guess like many small projects, they're too busy *doing* it to have
time to document it.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

John Meacham
In reply to this post by Jake Mcarthur-2
On Wed, Nov 26, 2008 at 03:29:43PM -0600, Jake McArthur wrote:
>> Interesting. I can't find out any information about this...
>
> It is a fork of the JHC compiler, which should be easier to look up.  
> There is also Hugs, as you mentioned. In addition, you may want to look  
> at YHC and NHC.

Hmm.. This one is news to me.

        John


--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Matthias Kilian
In reply to this post by Andrew Coppin
On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote:
> >It is a fork of the JHC compiler, which should be easier to look up.
> >There is also Hugs, as you mentioned. In addition, you may want to
> >look at YHC and NHC.
>
> Yeah, the "implementations" page on the Wiki basically says that there's
> GHC and Hugs, and there's also these things called YHC, NHC and JHC. All
> the documentation I've read makes these latter compilers sound highly
> experimental and unusable.

I would't call nhc experimental; it's quite usable, at least for
standard Haskell-98 stuff (plus some language extensions).

Ciao,
        Kili
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

David Menendez-2
On Wed, Nov 26, 2008 at 4:58 PM, Matthias Kilian <[hidden email]> wrote:

> On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote:
>> >It is a fork of the JHC compiler, which should be easier to look up.
>> >There is also Hugs, as you mentioned. In addition, you may want to
>> >look at YHC and NHC.
>>
>> Yeah, the "implementations" page on the Wiki basically says that there's
>> GHC and Hugs, and there's also these things called YHC, NHC and JHC. All
>> the documentation I've read makes these latter compilers sound highly
>> experimental and unusable.
>
> I would't call nhc experimental; it's quite usable, at least for
> standard Haskell-98 stuff (plus some language extensions).

How old is nhc? I've always thought of it as one of the "big three",
but I don't really know how far back it goes compared to ghc.


--
Dave Menendez <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Josef Svenningsson
On Wed, Nov 26, 2008 at 11:14 PM, David Menendez <[hidden email]> wrote:
> How old is nhc? I've always thought of it as one of the "big three",
> but I don't really know how far back it goes compared to ghc.
>
The following page suggests that it was released mid 1994 but there
could of course have been earlier releases.
http://www.cs.chalmers.se/pub/haskell/nhc/old/

Perhaps Malcolm Wallace knows more.

Cheers,

Josef
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Bernie Pope
In reply to this post by Andrew Coppin

On 27/11/2008, at 8:35 AM, Andrew Coppin wrote:

> Jake McArthur wrote:
>> Andrew Coppin wrote:
>>> Don Stewart wrote:
>>>> Noteworthy,
>>>>               * lhc-20081121: “Lhc Haskell Compiler”
>>>>
>>>
>>> Interesting. I can't find out any information about this...
>>
>> It is a fork of the JHC compiler, which should be easier to look  
>> up. There is also Hugs, as you mentioned. In addition, you may want  
>> to look at YHC and NHC.
>
> Yeah, the "implementations" page on the Wiki basically says that  
> there's GHC and Hugs, and there's also these things called YHC, NHC  
> and JHC. All the documentation I've read makes these latter  
> compilers sound highly experimental and unusable. (I don't recall  
> specifically which of them, but I remember hearing it can't even  
> compile the Prelude yet.) They seem like small projects which are  
> probably interesting to hack with, but not much use if you're trying  
> to produce production-grade compiled code to give to a customer...
>
> OTOH, I haven't ever attempted to *use* any of these compilers. I  
> only read about them...

Don't forget hbc.

There's plenty of information about all the compilers in the history  
of haskell paper, including a timeline:

     http://research.microsoft.com/users/simonpj/papers/history-of-haskell/index.htm

Cheers,
Bernie._______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Richard A. O'Keefe
In reply to this post by Andrew Coppin

On 27 Nov 2008, at 10:56 am, Andrew Coppin wrote:
> Donnie Jones wrote:
>> Here is the current homepage for the LHC project:
>>  http://lhc.seize.it/
>> Yes. I found that - it just didn't *say* very much. ;-)

I really really wish there were just one more sentence on
that page saying WHY there is a fork of JHC.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Jason Dagit-2


On Wed, Nov 26, 2008 at 6:19 PM, Richard O'Keefe <[hidden email]> wrote:

On 27 Nov 2008, at 10:56 am, Andrew Coppin wrote:
Donnie Jones wrote:
Here is the current homepage for the LHC project:
 http://lhc.seize.it/
Yes. I found that - it just didn't *say* very much. ;-)

I really really wish there were just one more sentence on
that page saying WHY there is a fork of JHC.

I spoke with the author of the fork a bit in IRC around the time it happened and my understanding is that:
1) John sternly objects to using cabal as the build system for JHC
2) JHC was seeing very little development activity by John
3) The author of the fork has philosophically different ideas about project management

I really hope JHC and LHC can continue to share code and are able to be collaborating projects instead of competing ones.

We can see that LHC already has an increase in activity and the new team that is forming is very interested in clean up and factorization.  That is, I've seen some good discussions about using libraries instead of project specific functionality between LHC contributors.

I hope John doesn't take the fork as any sort of aggressive or insulting action.  He's made a compiler that is sufficiently interesting to have users that want to take over.

I'm not involved in either fork in either way, but it's quite interesting to watch and I can see parallels to a different Haskell project.

Thanks,
Jason

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Brandon S Allbery KF8NH
In reply to this post by Matthias Kilian
On 2008 Nov 26, at 16:58, Matthias Kilian wrote:

> On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote:
>>> It is a fork of the JHC compiler, which should be easier to look up.
>>> There is also Hugs, as you mentioned. In addition, you may want to
>>> look at YHC and NHC.
>>
>> Yeah, the "implementations" page on the Wiki basically says that  
>> there's
>> GHC and Hugs, and there's also these things called YHC, NHC and  
>> JHC. All
>> the documentation I've read makes these latter compilers sound highly
>> experimental and unusable.
>
> I would't call nhc experimental; it's quite usable, at least for
> standard Haskell-98 stuff (plus some language extensions).


On a related topic:  whatever happened to the compiler shootout?  
(Aside from dons leaving unsw)

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Don Stewart-2
allbery:

> On 2008 Nov 26, at 16:58, Matthias Kilian wrote:
> >On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote:
> >>>It is a fork of the JHC compiler, which should be easier to look up.
> >>>There is also Hugs, as you mentioned. In addition, you may want to
> >>>look at YHC and NHC.
> >>
> >>Yeah, the "implementations" page on the Wiki basically says that  
> >>there's
> >>GHC and Hugs, and there's also these things called YHC, NHC and  
> >>JHC. All
> >>the documentation I've read makes these latter compilers sound highly
> >>experimental and unusable.
> >
> >I would't call nhc experimental; it's quite usable, at least for
> >standard Haskell-98 stuff (plus some language extensions).
>
>
> On a related topic:  whatever happened to the compiler shootout?  
> (Aside from dons leaving unsw)

Malcolm continues the tradition,

    http://code.haskell.org/nobench/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Adrian Neumann

Am 27.11.2008 um 09:23 schrieb Don Stewart:

> allbery:
>> On 2008 Nov 26, at 16:58, Matthias Kilian wrote:
>>> On Wed, Nov 26, 2008 at 09:35:01PM +0000, Andrew Coppin wrote:
>>>>> It is a fork of the JHC compiler, which should be easier to  
>>>>> look up.
>>>>> There is also Hugs, as you mentioned. In addition, you may want to
>>>>> look at YHC and NHC.
>>>>
>>>> Yeah, the "implementations" page on the Wiki basically says that
>>>> there's
>>>> GHC and Hugs, and there's also these things called YHC, NHC and
>>>> JHC. All
>>>> the documentation I've read makes these latter compilers sound  
>>>> highly
>>>> experimental and unusable.
>>>
>>> I would't call nhc experimental; it's quite usable, at least for
>>> standard Haskell-98 stuff (plus some language extensions).
>>
>>
>> On a related topic:  whatever happened to the compiler shootout?
>> (Aside from dons leaving unsw)
>
> Malcolm continues the tradition,
>
>     http://code.haskell.org/nobench/
All result links are broken.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

PGP.sig (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

John Meacham
In reply to this post by Jason Dagit-2
On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote:
> I spoke with the author of the fork a bit in IRC around the time it happened
> and my understanding is that:
> 1) John sternly objects to using cabal as the build system for JHC

This is a fairly silly reason to fork a project, especially jhc, for a
number of reasons.

It is important to me that jhc be as widely accessible at possible. The
number of machines './configure && make install' will work on outnumbers
those that cabal install will work on hundreds or thousands to
one. I am pleased to have anyone experiment with jhc in the first place, I
don't want to make things harder for my users. This alone would be
enough of a reason all other things being equal, but other things arn't
equal to boot.

The quality of support I can provide is diminished with cabal. Someone
tries to compile jhc, they get a moderately tricky build error. they
send it to me, I take a look, figure out the workaround and release a
new version that same day. one day turnaround. A bug is found in the way
cabal does something.  I track down the bug, hope it is something
fixable, then further hope when I send a fix it is accepted. Maybe it
takes a week or two. Now, do I release a new version of jhc that
requires a development version of cabal? do I hold off and tell the user
they need a personalized workaround? do I demand that to use jhc you
have to use the latest cabal snapshots? Do I then have to support them
when the latest snapshots break something else of theirs? In any case.
it is not a situation I want to be in.

Cabal just isn't elegant. let's put it in perspective, cabal has 4 times
as many lines of code as mk (a superset of make)*. That is four times as
many lines of haskell code as C. Given how much more dense and
expressive haskell code is than C, that is a huge amount. Yet cabal
can't handle what even mildly complicated make scripts can do.


Cabal is not flexible. I decide I want to include a nice graph of code
motion in jhc, so I add the following 2 lines to my makefile

> %.pdf: %.dot
>     dot $< -Tpdf -o$@

and done! my build system now understands how to create pdf documents
from graph description files. now, I _could_ add support for this to
cabal, I _could_ wait several months for the new version to propagate to
users. And I _would_ fully expect to have to go through the whole
process again the next time I want to do something slightly unorthodox.


Cabal is just a huge dependency I don't need. Every dependency I add to
a project is a bigger hassle for my users and for me. A fairly
complicated dependency like cabal would have to have fairly compelling
benefits.


Now, I am saying these things so people don't think I am just being
stubborn. I have valid, compelling, and logical reasons to not want to
use cabal. I think it is the wrong tool for the job and it is that
simple. If you want me to switch to cabal, address its issues, and
then _in addition_ add a killer feature on top to put it ahead of other
systems to make the work involved in switching worth it. I have a goal
with jhc, to write a kick ass haskell compiler. Not to fight a build
system that is not suited to my task and that made some dubious design
decisions. Not to promote an agenda.

And before you respond, think about this. What if the ghc developers
were constantly bombarded with whining from the perl people that ghc
doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What
would your impression of the perl community be?

What if people kept trying to convince _you_ to rewrite your haskell
project in java _and_ provide support for it because "they never had to
use referential transparency, so it can't be that important to you".

Sometimes that is what it feels like, which is disapointing from this
community. We all came to haskell because we thought it was the better
choice at some point. The hegemony was pushing java, C++, or worse but
we didn't bite (or at least were still hungry).  Just because something
is popular, it doesn't mean it is good, just because it is written in
haskell, it doesn't mean it is elegant. So don't begrudge me for holding
out for something better. Perhaps franchise will be it, perhaps some
future version of cabal, perhaps nothing will replace make/autoconfs
sweet spot (though I would hope there is still some innovation in this
area the OSS community can explore).  


> I hope John doesn't take the fork as any sort of aggressive or insulting
> action.  He's made a compiler that is sufficiently interesting to have users
> that want to take over.

I am still actively working on jhc for the record. Actual code checkin
tends to be very spurty, but don't think the project is dead. More in a
design phase than anything else. There is no surer way to instigate
another spurt than by submitting some patches or bringing up discussion
of an interesting topic or paper on the jhc mailing list.

        John


* if you include the source of all the libraries mk depends on, cabal
  still has twice as many lines.


--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Don Stewart-2
john:
> On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote:
> > I spoke with the author of the fork a bit in IRC around the time it happened
> > and my understanding is that:
> > 1) John sternly objects to using cabal as the build system for JHC
>
> This is a fairly silly reason to fork a project, especially jhc, for a
> number of reasons.

One of the reasons though, for the branching, is that the potential
developers, who all have Haskell toolchains, couldn't do:

    $ cabal install jhc

Then now can, but have to write 'lhc' instead of 'jhc'.

We've probably just increased the jhc "alpha user" base 10 fold. Hooray!

Integrating into the ecology of the vast majority of Haskell code is a
good way to get and keep developers. And since GHC -- which we need to
build JHC anyway -- already ships with Cabal, no additional dependencies
are required.

Looks like win to me.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

Jason Dagit-2
In reply to this post by John Meacham


On Fri, Nov 28, 2008 at 7:30 PM, John Meacham <[hidden email]> wrote:
On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote:
> I spoke with the author of the fork a bit in IRC around the time it happened
> and my understanding is that:
> 1) John sternly objects to using cabal as the build system for JHC

This is a fairly silly reason to fork a project, especially jhc, for a
number of reasons.

It is important to me that jhc be as widely accessible at possible. The
number of machines './configure && make install' will work on outnumbers
those that cabal install will work on hundreds or thousands to
one. I am pleased to have anyone experiment with jhc in the first place, I
don't want to make things harder for my users. This alone would be
enough of a reason all other things being equal, but other things arn't
equal to boot.
 
The command './configure && make install' only works in Windows if the user bother to install some form of unix environment emulation like msys or cygwin.  I don't know if windows platform support matters to jhc, but if it does that's one reason to want to provide an alternative to the autotools build option.
 


The quality of support I can provide is diminished with cabal. Someone
tries to compile jhc, they get a moderately tricky build error. they
send it to me, I take a look, figure out the workaround and release a
new version that same day. one day turnaround. A bug is found in the way
cabal does something.  I track down the bug, hope it is something
fixable, then further hope when I send a fix it is accepted. Maybe it
takes a week or two. Now, do I release a new version of jhc that
requires a development version of cabal? do I hold off and tell the user
they need a personalized workaround? do I demand that to use jhc you
have to use the latest cabal snapshots? Do I then have to support them
when the latest snapshots break something else of theirs? In any case.
it is not a situation I want to be in.

Cabal just isn't elegant. let's put it in perspective, cabal has 4 times
as many lines of code as mk (a superset of make)*. That is four times as
many lines of haskell code as C. Given how much more dense and
expressive haskell code is than C, that is a huge amount. Yet cabal
can't handle what even mildly complicated make scripts can do.


Cabal is not flexible. I decide I want to include a nice graph of code
motion in jhc, so I add the following 2 lines to my makefile

> %.pdf: %.dot
>     dot $< -Tpdf -o$@

and done! my build system now understands how to create pdf documents
from graph description files. now, I _could_ add support for this to
cabal, I _could_ wait several months for the new version to propagate to
users. And I _would_ fully expect to have to go through the whole
process again the next time I want to do something slightly unorthodox.


Cabal is just a huge dependency I don't need. Every dependency I add to
a project is a bigger hassle for my users and for me. A fairly
complicated dependency like cabal would have to have fairly compelling
benefits.
 
Your arguments make it sound as though providing an option for building with cabal is out of the question.  Since I'm not invovled with JHC or LHC in any way I don't know how you would answer this question: Would you consider a cabal based build inaddition to the autotools one?
 
 Personally, I look at it this way.  Both build systems have different advantages that the other cannot provide but they are not mutually exclusive.  Also, the effort to keep them both working for the respective groups of users is rather small in practice.
 


Now, I am saying these things so people don't think I am just being
stubborn. I have valid, compelling, and logical reasons to not want to
use cabal. I think it is the wrong tool for the job and it is that
simple. If you want me to switch to cabal, address its issues, and
then _in addition_ add a killer feature on top to put it ahead of other
systems to make the work involved in switching worth it. I have a goal
with jhc, to write a kick ass haskell compiler. Not to fight a build
system that is not suited to my task and that made some dubious design
decisions. Not to promote an agenda.
 
The reason to provide a .cabal file is exactly the one Don wrote about.  This is possible both using make as the build system or in a way that is independent of the make based build system.
 


And before you respond, think about this. What if the ghc developers
were constantly bombarded with whining from the perl people that ghc
doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What
would your impression of the perl community be?
 
I don't recall if I've expressed this publicly before or not, but I'm not fond of the language specific reimplementations of make.  I think it's silly that every language has 2-3 language specific build systems and package formats.  But, it's too late for me to stop Cabal from existing.  Hackage is too useful to ignore.  Using it increases my productivity.  Tools that use the Cabal format save me time and give me cool features for free.  I can easily run haddock or module graphs for example.  So, in short, if the perl community had a compelling argument based on what GHC is missing out on, then I think it would be fine for them to bring that to the attention of GHC HQ.
 
Now, the next point.  I think you're getting carried away here.  This fork was created without you being aware of it.  That makes me think the author of the fork didn't bombard you with whining.  So, I think we need to keep some perspective on that.  It's natural that you should have a fair bit of emotional attachment to the JHC -- you'd be weird if you didn't -- but as I've said before, I don't think any of this is an attack on you or JHC.  Rather I think it's a fondness for JHC plus a desire to try different things.
 


What if people kept trying to convince _you_ to rewrite your haskell
project in java _and_ provide support for it because "they never had to
use referential transparency, so it can't be that important to you".
 
When this comes up on the Darcs mailing list we tend to explain why we like Haskell and then encourage them to try a reimplementation in their favorite language if they want to.  I think that parallels the situation here.  Someone thought he could do better by doing X and Y and instead of expecting you to support that went off and made a fork where he can support that. 


Sometimes that is what it feels like, which is disapointing from this
community. We all came to haskell because we thought it was the better
choice at some point. The hegemony was pushing java, C++, or worse but
we didn't bite (or at least were still hungry).  Just because something
is popular, it doesn't mean it is good, just because it is written in
haskell, it doesn't mean it is elegant. So don't begrudge me for holding
out for something better. Perhaps franchise will be it, perhaps some
future version of cabal, perhaps nothing will replace make/autoconfs
sweet spot (though I would hope there is still some innovation in this
area the OSS community can explore).
 
Well, I came to Haskell because I had university courses that introduced me to it, then I started using Darcs and realized I wanted to contribute to Darcs so I learned more Haskell.  In the process, my old favorite language Common Lisp was replaced by my new favorite Haskell. I tell people that I now prefer Haskell because: a) The static guarantees you can get really are useful b) the language and paradigm fit the way I think c) the community is full of exteremely intelligent people that care about the quality of the code they write d) the community is friendly and growing.  I think animonsity towards Java and C++ is silly.  Those languages have their merit, their strengths and their place.
 
I don't see how using Cabal for it's strengths today and make for its strengths prevents you from using the next cool thing when it gets here.
 

> I hope John doesn't take the fork as any sort of aggressive or insulting
> action.  He's made a compiler that is sufficiently interesting to have users
> that want to take over.

I am still actively working on jhc for the record. Actual code checkin
tends to be very spurty, but don't think the project is dead. More in a
design phase than anything else. There is no surer way to instigate
another spurt than by submitting some patches or bringing up discussion
of an interesting topic or paper on the jhc mailing list.
 
That's good to hear.
 
 Thanks for your time, and I wish both projects well with lots of collaboration!
Jason

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Compilers

John Meacham
In reply to this post by Don Stewart-2
On Fri, Nov 28, 2008 at 07:41:42PM -0800, Don Stewart wrote:

> john:
> > On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote:
> > > I spoke with the author of the fork a bit in IRC around the time it happened
> > > and my understanding is that:
> > > 1) John sternly objects to using cabal as the build system for JHC
> >
> > This is a fairly silly reason to fork a project, especially jhc, for a
> > number of reasons.
>
> One of the reasons though, for the branching, is that the potential
> developers, who all have Haskell toolchains, couldn't do:
>
>     $ cabal install jhc
>
> Then now can, but have to write 'lhc' instead of 'jhc'.
>
> We've probably just increased the jhc "alpha user" base 10 fold. Hooray!

Except that for all those systems that can use cabal, ./configure &&
make install would have already worked perfectly. So in actuality my
alpha user base drops 50-fold.

Also, I am not so sure who these people are who are willing to type 10
characters to try out jhc, but not a dozen more. I mean, a few typos and
there won't be enough keystrokes in their budget to compile hello world,
let alone provide a bug report or send a patch :)


I think you are overestimating the penetration of cabal or
underestimating the size and diversity of the haskell user base. There
are a whole lot of people out there who just want to use haskell and
don't keep up with the IRC channels or the mailing lists. Grad students
interested in some aspect of jhcs design  who did apt-get install ghc
and then expect jhc to work. Sysadmins who manage clusters of computers
for work but have no particular attachement to haskell whose kickstart
scripts allow just dropping in an autoconfed tarball but have to be
retooled for something new?


> Integrating into the ecology of the vast majority of Haskell code is a
> good way to get and keep developers. And since GHC -- which we need to
> build JHC anyway -- already ships with Cabal, no additional dependencies
> are required.

But wouldn't it be nicer if Haskell fit into the ecology of OSS in
general? Even better wouldn't it be nice if peoples first impression of
haskell was not annoyance at having to build a package in some
proprietary way , but rather being impressed with some piece of software
and looking into its implementation and seeing how it got to be so good?
No one when just trying to install a random program not knowing anything
about the implementation gets excited at seeing that they have to learn
some brand new way of getting it to work.

For a standalone program like jhc, integrating with the open source
community as a whole, and having the flexibility of working with the
right tool for the task at hand are very desirable things.

When it comes down to it, an actual reason to use cabal is not there, If
the reason is to fit into the ecology of Haskell code, then my question
is why is this ecology so distinct to begin with? What is wrong with
haskell such that its world must be so disjoint from that of other
languages?  That seems to be the real WTF here that needs fixing.

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
123