Re: [Haskell-cafe] Compilers book in Haskell

[Kristopher Micinski]

A swapped order probably appeals to most haskellers (by contrast I
first learned ML).  The real difference is that the Haskell books will
focus on lazy languages.  If your tastes are in implementing fast lazy
languages using graph reduction then you may also be interested in
[1]: although I haven't read all of it.  I would say that the material
in Appel's books and SPJ's books is fairly disjoint, and if you're
interested in Haskell you should definitely focus on those.  (However,
Appel's book is also worth browsing if you're at a library, it can be
read fairly quickly, the main "cool concepts" are in chapter two!)

Kris

[1] 
http://wiki.clean.cs.ru.nl/Functional_Programming_and_Parallel_Graph_Rewriting

On Sun, Apr 7, 2013 at 9:00 PM, Tommy Thorn  wrote:
> You beat me to it although I'd reverse the order of your list.
>
> Also I wouldn't ignore the classic,
> http://www.amazon.com/Compilers-Principles-Techniques-Tools-Edition/dp/0321486811
> but know that it has next to nothing useful specific to FP languages,
> and certainly not lazy languages.
>
> Tommy
>
> On Apr 7, 2013, at 07:40 , Kristopher Micinski  wrote:
>
>> I disagree about the recommendation for Modern Compiler Design: I
>> found it to be a pretty good introduction to compiler technology, but
>> not functional programming with compilers, it's coverage was *very*
>> shallow.
>>
>> By contrast, I can recommend both Compiling with Continuations (the
>> "standard" text on implementing compilers in functional languages,
>> using ML as an example), and The Implementation of Functional
>> Programming Languages [2].
>>
>> This topic is covered pretty well in course material scattered
>> throughout the web, (lots of course with online pdf sets about
>> implementing functional compilers), but not in a comprehensive fashion
>> that talks about more complex aspects of compiling functional
>> languages.  Implementing Functional Langauges: a tutorial, is also
>> excellent and worth a look.
>>
>> kris
>>
>> [1] 
>> http://www.amazon.com/Compiling-Continuations-Andrew-W-Appel/dp/052103311X
>> [2] 
>> http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm
>> [3] 
>> http://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/
>>
>> On Sun, Apr 7, 2013 at 4:36 AM, Sergey Bushnyak
>>  wrote:
>>> Books about compilers is rare artifact, in comparison to some technology
>>> books. It is uncommon to see topics on compilers for functional languages.
>>>
>>> I was surprised, when saw it in "Modern Compiler Design", which I've
>>> mentioned earlier. "Compiler design" series from Springer maybe reveal
>>> topics on FL in future as it become more popular. In new books about 1/5 of
>>> it is about FL, but very basic stuff.
>>>
>>> Кnowledge mostly lies in research papers, occasional articles like "The
>>> Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :)
>>>
>>>
>>> [1] http://www.aosabook.org/en/ghc.html
>>>
>>> --
>>> Best regards,
>>> Sergey Bushnyak
>>>
>>>
>>> ___
>>> 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] Compilers book in Haskell

[Tommy Thorn]

You beat me to it although I'd reverse the order of your list.

Also I wouldn't ignore the classic,
http://www.amazon.com/Compilers-Principles-Techniques-Tools-Edition/dp/0321486811
but know that it has next to nothing useful specific to FP languages,
and certainly not lazy languages.

Tommy

On Apr 7, 2013, at 07:40 , Kristopher Micinski  wrote:

> I disagree about the recommendation for Modern Compiler Design: I
> found it to be a pretty good introduction to compiler technology, but
> not functional programming with compilers, it's coverage was *very*
> shallow.
> 
> By contrast, I can recommend both Compiling with Continuations (the
> "standard" text on implementing compilers in functional languages,
> using ML as an example), and The Implementation of Functional
> Programming Languages [2].
> 
> This topic is covered pretty well in course material scattered
> throughout the web, (lots of course with online pdf sets about
> implementing functional compilers), but not in a comprehensive fashion
> that talks about more complex aspects of compiling functional
> languages.  Implementing Functional Langauges: a tutorial, is also
> excellent and worth a look.
> 
> kris
> 
> [1] http://www.amazon.com/Compiling-Continuations-Andrew-W-Appel/dp/052103311X
> [2] 
> http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm
> [3] 
> http://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/
> 
> On Sun, Apr 7, 2013 at 4:36 AM, Sergey Bushnyak
>  wrote:
>> Books about compilers is rare artifact, in comparison to some technology
>> books. It is uncommon to see topics on compilers for functional languages.
>> 
>> I was surprised, when saw it in "Modern Compiler Design", which I've
>> mentioned earlier. "Compiler design" series from Springer maybe reveal
>> topics on FL in future as it become more popular. In new books about 1/5 of
>> it is about FL, but very basic stuff.
>> 
>> Кnowledge mostly lies in research papers, occasional articles like "The
>> Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :)
>> 
>> 
>> [1] http://www.aosabook.org/en/ghc.html
>> 
>> --
>> Best regards,
>> Sergey Bushnyak
>> 
>> 
>> ___
>> 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] Compilers book in Haskell

[Kristopher Micinski]

I disagree about the recommendation for Modern Compiler Design: I
found it to be a pretty good introduction to compiler technology, but
not functional programming with compilers, it's coverage was *very*
shallow.

By contrast, I can recommend both Compiling with Continuations (the
"standard" text on implementing compilers in functional languages,
using ML as an example), and The Implementation of Functional
Programming Languages [2].

This topic is covered pretty well in course material scattered
throughout the web, (lots of course with online pdf sets about
implementing functional compilers), but not in a comprehensive fashion
that talks about more complex aspects of compiling functional
languages.  Implementing Functional Langauges: a tutorial, is also
excellent and worth a look.

kris

[1] http://www.amazon.com/Compiling-Continuations-Andrew-W-Appel/dp/052103311X
[2] 
http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm
[3] http://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/

On Sun, Apr 7, 2013 at 4:36 AM, Sergey Bushnyak
 wrote:
> Books about compilers is rare artifact, in comparison to some technology
> books. It is uncommon to see topics on compilers for functional languages.
>
> I was surprised, when saw it in "Modern Compiler Design", which I've
> mentioned earlier. "Compiler design" series from Springer maybe reveal
> topics on FL in future as it become more popular. In new books about 1/5 of
> it is about FL, but very basic stuff.
>
> Кnowledge mostly lies in research papers, occasional articles like "The
> Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :)
>
>
> [1] http://www.aosabook.org/en/ghc.html
>
> --
> Best regards,
> Sergey Bushnyak
>
>
> ___
> 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] Compilers book in Haskell

[Andrés Sicard-Ramírez]

On Sat, Apr 6, 2013 at 10:34 PM, Andrés Sicard-Ramírez <
andres.sicard.rami...@gmail.com> wrote:

> Juan, te puede interesar
>
> On Sat, Apr 6, 2013 at 5:56 PM, Sergey Bushnyak <
> sergey.bushn...@sigrlami.eu> wrote:
>
>> I will recommend you book "Modern Compiler Design" by Dick Grune and
>> others.
>> Besides discussing different topics, authors use Haskell as example for
>> describing ideas behind compilers for functional language.
>>
>
>
Sorry for the spam. The above email should not be sent to haskell-cafe.

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

Re: [Haskell-cafe] Compilers book in Haskell

[Sergey Bushnyak]

Books about compilers is rare artifact, in comparison to some technology 
books. It is uncommon to see topics on compilers for functional languages.


I was surprised, when saw it in "Modern Compiler Design", which I've 
mentioned earlier. "Compiler design" series from Springer maybe reveal 
topics on FL in future as it become more popular. In new books about 1/5 
of it is about FL, but very basic stuff.


Кnowledge mostly lies in research papers, occasional articles like "The 
Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :)



[1] http://www.aosabook.org/en/ghc.html

--
Best regards,
Sergey Bushnyak


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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[wren ng thornton]

On 11/25/12 11:08 PM, Richard O'Keefe wrote:


On 24/11/2012, at 5:26 PM, wren ng thornton wrote:


On 11/20/12 6:54 AM, c...@lavabit.com wrote:

Hello,

I know nothing about compilers and interpreters. I checked several
books, but none of them explained why we have to translate a
high-level language into a small (core) language. Is it impossible
(very hard) to directly translate high-level language into machine
code?


It is possible to remove stages in the standard compilation pipeline, and doing 
so can speed up compilation time. For example, Perl doesn't build an abstract 
syntax tree (for now-outdated performance reasons), and instead compiles the 
source language directly into bytecode (which is then interpreted by the 
runtime). This is one of the reasons why Perl is (or was?) so much faster than 
other interpreted languages like Python etc.


I have found Perl anything from the same speed as AWK (reading and writing
lots of data with hardly any processing) to 10 times slower than AWK (with
respect to the 'mawk' implementation of AWK).


Perhaps I was too glib in saying "other interpreted languages"; I 
certainly did not mean to include Sed and Awk (which I tend to consider 
shell scripting more than interpreted programming). Also, I'm only 
referring to the startup cost of parsing and compiling to bytecode[1], 
not any other overhead of the actual languages themselves. There are 
significant differences between the actual content of each language[2], 
but that's a linguistic issue rather than an issue of how to design and 
structure the compiler/interpreter.



[1] For one-liners and short programs, this startup cost tends to 
dominate, which is why Perl does direct to bytecode. Perl was initially 
intended to be a combination/replacement for Sed, Awk, Bash, etc; it 
only turned into a full programming language later. That said, the 
overhead for starting the Perl runtime is much higher than for Sed and 
Awk, which is why many systems engineers still use Sed/Awk in their scripts.



[2] A notorious but too poorly known example is the implementation of 
regexes where crufty old tools/languages like awk and grep vastly 
outperform modern tools like Perl and Python:


http://swtch.com/~rsc/regexp/regexp1.html

To say nothing of the implementations of strings, hash tables, etc; 
which you mentioned.


--
Live well,
~wren

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Richard O'Keefe]

On 24/11/2012, at 5:26 PM, wren ng thornton wrote:

> On 11/20/12 6:54 AM, c...@lavabit.com wrote:
>> Hello,
>> 
>> I know nothing about compilers and interpreters. I checked several
>> books, but none of them explained why we have to translate a
>> high-level language into a small (core) language. Is it impossible
>> (very hard) to directly translate high-level language into machine
>> code?
> 
> It is possible to remove stages in the standard compilation pipeline, and 
> doing so can speed up compilation time. For example, Perl doesn't build an 
> abstract syntax tree (for now-outdated performance reasons), and instead 
> compiles the source language directly into bytecode (which is then 
> interpreted by the runtime). This is one of the reasons why Perl is (or was?) 
> so much faster than other interpreted languages like Python etc.

I have found Perl anything from the same speed as AWK (reading and writing
lots of data with hardly any processing) to 10 times slower than AWK (with
respect to the 'mawk' implementation of AWK).

The deeply saddening thing here is that there are lots of improvements I
_know_ how to make to mawk to make it even faster, but the thing that stops
me is the way mawk generates word-code directly without an AST.

I don't know why Perl is direct-to-byte-code, but I'm pretty sure why mawk
is direct-to-word-code and The One True Awk interprets its AST.  AWK used
to run on PDP-11s and for large source files had room for VM instructions
or ASTs but not both at the same time.

Designing a compiler for fast *compiling* leads to one kind of
design; designing for fast *running* of generated code leads to another.

And run times for scripting languages depends on things like the structure
of hash tables, the quality of hashing functions, the cripplingly excessive
richness of certain regular expression libraries, the memory management
scheme, ...



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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[wren ng thornton]

On 11/20/12 6:54 AM, c...@lavabit.com wrote:

Hello,

I know nothing about compilers and interpreters. I checked several
books, but none of them explained why we have to translate a
high-level language into a small (core) language. Is it impossible
(very hard) to directly translate high-level language into machine
code?


It is possible to remove stages in the standard compilation pipeline, 
and doing so can speed up compilation time. For example, Perl doesn't 
build an abstract syntax tree (for now-outdated performance reasons), 
and instead compiles the source language directly into bytecode (which 
is then interpreted by the runtime). This is one of the reasons why Perl 
is (or was?) so much faster than other interpreted languages like Python 
etc. But there are some big problems to beware of:


* Not having a concrete representation for intermediate forms can rule 
out performing obvious optimizations. And I do mean *obvious* 
optimizations; I can talk more about this problem in Perl, if you really 
care.


* Not having a concrete representation for intermediate forms means 
mixing together code from many different stages of the compilation 
process. This sort of spaghetti code is hard to maintain, and even 
harder to explain to new developers.


* Not having a concrete representation for intermediate forms can lead 
to code duplication (in the compiler) because there's no convenient way 
to abstract over certain patterns. And, of course, repeating code is 
just begging for inconsistency bugs due to the maintenance burden of 
keeping all the copies in sync.


All three points are major driving forces in having intermediate forms. 
Joachim Breitner gave some illustrations for why intermediate forms are 
"inevitable". But then, once you have intermediate forms, if you're 
interested in ensuring correctness and having a formal(izable) 
semantics, then it makes sense to try to turn those intermediate forms 
into an actual intermediate language. Intermediate forms are just an 
implementation detail, but intermediate languages can be reasoned about 
in the same ways as other languages. So it's more about shifting 
perspective in order to turn systems problems (implementation details) 
into language problems (semantics of the Core).


Furthermore, if you're a PL person and really are trying to ensure 
correctness of your language (e.g., type safety), you want to try to 
make your proof obligation as small as possible. For convenience to 
programmers, source code is full of constructs which are all more or 
less equivalent. But this is a problem for making proofs because when we 
perform case analysis on an expression we have to deal with all those 
different syntactic forms. Whereas if you first compile everything down 
into a small core language, then the proof has far fewer syntactic forms 
it has to deal with and so the proof is much easier. Bear in mind that 
this isn't just a linear problem. If we have N different syntactic 
forms, then proving something like confluence will require proving 
O(N^2) cases since you're comparing two different terms.


--
Live well,
~wren

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Jacques Carette]

On 23/11/2012 9:59 AM, Mike Meyer wrote:
[...] I have to ask if your core language for Maple was larger than 
Maple? 


Yes. Maple 10 had 62 cases in its AST, we had 75 (p.13 of [1])

Jacques

[1] http://www.cas.mcmaster.ca/~carette/publications/scp_MaplePE.pdf

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Brandon Allbery]

On Fri, Nov 23, 2012 at 9:59 AM, Mike Meyer  wrote:

> I have to ask if your core language for Maple was larger than Maple?


I can think of several reasons why it would make sense, especially if the
core language is much harder for a human to write for but much easier to
optimize and/or generate machine code for.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Mike Meyer]

Jacques Carette  wrote:

>On 22/11/2012 11:52 AM, Brandon Allbery wrote:
>> On Thu, Nov 22, 2012 at 7:56 AM, Jacques Carette 
>> > wrote:
>>
>> On 20/11/2012 6:08 PM, Richard O'Keefe wrote:
>>
>> On 21/11/2012, at 4:49 AM, > > wrote:
>>
>> Well, I don't know. Would it save some time? Why bother
>> with a core language?
>>
>> For a high level language (and for this purpose, even Fortran
>> 66 counts as
>> "high level") you really don't _want_ a direct translation
>> from source code
>> to object code.  You want to eliminate unused code and you
>> want to do all
>> sorts of analyses and improvements.  It is *much* easier to
>do
>> all that to
>> a small core language than to the full source language.
>>
>>
>> Actually, here I disagree.  It might be much 'easier' for the
>> programmers to do it for a small core language, but it may turn
>> out to be much, much less effective.  I 'discovered' this when
>> (co-)writing a partial evaluator for Maple: 
>>
>>
>> You're still using a core language, though; just with a slightly 
>> different focus than Haskell's.  I already mentioned gcc's internal 
>> language, which similarly is larger (semantically; syntactically it's
>
>> sexprs).  What combination is more appropriate depends on the
>language 
>> and the compiler implementation.
>
>Right, we agree: it is not 'core language' I disagreed with, it is 
>'smaller core language'.  And we also agree that smaller/larger depends
>on the eventual application.  But 'smaller core language' is so 
>ingrained as "conventional wisdom" that I felt compelled to offer 
>evidence against this bit of folklore.

I don't think you're evidence contacts that bit of folklore. But as stated it's 
vague. In particular, is "smaller"  relative to the full source language, or is 
it absolute (in which case you should compile to a RISC architecture and 
optimize that :-)? Since the latter seems silly, I have to ask if your core 
language for Maple was larger than Maple?
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Jacques Carette]

On 22/11/2012 7:37 PM, Richard O'Keefe wrote:

On 23/11/2012, at 1:56 AM, Jacques Carette wrote:

Actually, here I disagree. It might be much 'easier' for the 
programmers to do it for a small core language, but it may turn out 
to be much, much less effective. I 'discovered' this when 
(co-)writing a partial evaluator for Maple: we actually made our 
internal language *larger*, so that we could encode more invariants 
syntactically. This ended up making our jobs considerably easier, 
because we did not have to work so hard on doing fancy analyses to 
recover information that would otherwise have been completely 
obvious. Yes, there were a lot more cases, but each case was 
relatively easy; the alternative was a small number of extremely 
difficult cases. 

I don't think we do disagree.  We are talking about the same thing:
``not hav[ing] to work so hard on doing fancy analyses''.
The key point is that an (abstract) syntax *designed for the compiler*
and a syntax *designed for programmers* have to satisfy different
design goals and constraints; there's no reason they should be the same.


I must have mis-interpreted what you said then.  We definitely agree on 
this key point.


Jacques



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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Jacques Carette]

On 22/11/2012 11:52 AM, Brandon Allbery wrote:
On Thu, Nov 22, 2012 at 7:56 AM, Jacques Carette > wrote:


On 20/11/2012 6:08 PM, Richard O'Keefe wrote:

On 21/11/2012, at 4:49 AM, mailto:c...@lavabit.com>> wrote:

Well, I don't know. Would it save some time? Why bother
with a core language?

For a high level language (and for this purpose, even Fortran
66 counts as
"high level") you really don't _want_ a direct translation
from source code
to object code.  You want to eliminate unused code and you
want to do all
sorts of analyses and improvements.  It is *much* easier to do
all that to
a small core language than to the full source language.


Actually, here I disagree.  It might be much 'easier' for the
programmers to do it for a small core language, but it may turn
out to be much, much less effective.  I 'discovered' this when
(co-)writing a partial evaluator for Maple: 



You're still using a core language, though; just with a slightly 
different focus than Haskell's.  I already mentioned gcc's internal 
language, which similarly is larger (semantically; syntactically it's 
sexprs).  What combination is more appropriate depends on the language 
and the compiler implementation.


Right, we agree: it is not 'core language' I disagreed with, it is 
'smaller core language'.  And we also agree that smaller/larger depends 
on the eventual application.  But 'smaller core language' is so 
ingrained as "conventional wisdom" that I felt compelled to offer 
evidence against this bit of folklore.


Jacques

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[KC]

I believe the question you are asking is why do large software systems
need to be designed in terms of levels or some other software
engineering construct(s).

To manage their complexity as opposed to getting mangled in their complexity. :D


-- 
--
Regards,
KC

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Richard O'Keefe]

On 23/11/2012, at 1:56 AM, Jacques Carette wrote:

> On 20/11/2012 6:08 PM, Richard O'Keefe wrote:
>> On 21/11/2012, at 4:49 AM,  wrote:
>> 
>>> Well, I don't know. Would it save some time? Why bother with a core 
>>> language? 
>> For a high level language (and for this purpose, even Fortran 66 counts as
>> "high level") you really don't _want_ a direct translation from source code
>> to object code.  You want to eliminate unused code and you want to do all
>> sorts of analyses and improvements.  It is *much* easier to do all that to
>> a small core language than to the full source language.
> 
> Actually, here I disagree.  It might be much 'easier' for the programmers to 
> do it for a small core language, but it may turn out to be much, much less 
> effective.  I 'discovered' this when (co-)writing a partial evaluator for 
> Maple: we actually made our internal language *larger*, so that we could 
> encode more invariants syntactically.  This ended up making our jobs 
> considerably easier, because we did not have to work so hard on doing fancy 
> analyses to recover information that would otherwise have been completely 
> obvious.  Yes, there were a lot more cases, but each case was relatively 
> easy; the alternative was a small number of extremely difficult cases.

I don't think we do disagree.  We are talking about the same thing:
``not hav[ing] to work so hard on doing fancy analyses''.
The key point is that an (abstract) syntax *designed for the compiler*
and a syntax *designed for programmers* have to satisfy different
design goals and constraints; there's no reason they should be the same.

As a very very crude example of this, with its user-defined operators,
Prolog lets you write rules using lots of (unquoted) operators
to express yourself in an quasi-English sort of way, e.g.,
if Block must move and top of Block is not clear
   then clear top of Block.
Readable.  But lousy for processing.  You'd want to change it to
something like
action(clear_top(Block), [
must_move(Block),
\+ top_is_clear(Block)]).



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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Brandon Allbery]

On Thu, Nov 22, 2012 at 7:56 AM, Jacques Carette wrote:

> On 20/11/2012 6:08 PM, Richard O'Keefe wrote:
>
>> On 21/11/2012, at 4:49 AM,  wrote:
>>
>>  Well, I don't know. Would it save some time? Why bother with a core
>>> language?
>>>
>> For a high level language (and for this purpose, even Fortran 66 counts as
>> "high level") you really don't _want_ a direct translation from source
>> code
>> to object code.  You want to eliminate unused code and you want to do all
>> sorts of analyses and improvements.  It is *much* easier to do all that to
>> a small core language than to the full source language.
>>
>
> Actually, here I disagree.  It might be much 'easier' for the programmers
> to do it for a small core language, but it may turn out to be much, much
> less effective.  I 'discovered' this when (co-)writing a partial evaluator
> for Maple:


You're still using a core language, though; just with a slightly different
focus than Haskell's.  I already mentioned gcc's internal language, which
similarly is larger (semantically; syntactically it's sexprs).  What
combination is more appropriate depends on the language and the compiler
implementation.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Jacques Carette]

On 20/11/2012 6:08 PM, Richard O'Keefe wrote:

On 21/11/2012, at 4:49 AM,  wrote:

Well, I don't know. Would it save some time? Why bother with a core 
language? 

For a high level language (and for this purpose, even Fortran 66 counts as
"high level") you really don't _want_ a direct translation from source code
to object code.  You want to eliminate unused code and you want to do all
sorts of analyses and improvements.  It is *much* easier to do all that to
a small core language than to the full source language.


Actually, here I disagree.  It might be much 'easier' for the 
programmers to do it for a small core language, but it may turn out to 
be much, much less effective.  I 'discovered' this when (co-)writing a 
partial evaluator for Maple: we actually made our internal language 
*larger*, so that we could encode more invariants syntactically.  This 
ended up making our jobs considerably easier, because we did not have to 
work so hard on doing fancy analyses to recover information that would 
otherwise have been completely obvious.  Yes, there were a lot more 
cases, but each case was relatively easy; the alternative was a small 
number of extremely difficult cases.


Jacques

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Richard O'Keefe]

On 21/11/2012, at 4:49 AM,  wrote:

>> What would be the point in doing so?
> 
> Well, I don't know. Would it save some time? Why bother with a core language?

For a high level language (and for this purpose, even Fortran 66 counts as
"high level") you really don't _want_ a direct translation from source code
to object code.  You want to eliminate unused code and you want to do all
sorts of analyses and improvements.  It is *much* easier to do all that to
a small core language than to the full source language.



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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Sturdy, Ian]

> * It can also be easier to apply high level optimization techniques;
> if you go straight from the highest level code to the lowest level, 
> you are likely to miss optimization opportunities that are only 
> revealed (or only sanely implementable) at intermediate levels.

Not to mention that since optimizations are often expressed as replacements 
(note how stream fusions are implemented), optimizing after desugaring reduces 
the number of patterns an optimization needs to match against.

By my understanding, GHC does not compile to core and then reparse the core 
file; 'core' is merely the name given to a certain stage in syntax tree 
manipulations. Thus, a compiler with no analogue of core would forego all 
syntax tree manipulations, instead taking the raw parse tree and running the 
code generator on that. And while that can be done for a sufficiently simple 
language, for a language with the complexity of Haskell I dare say that it is 
impossible:

> Because... have you ever tried to write a type-checker for character sequence?

>I'm sure some mad genius can do it, but I don't want to be that mad genius.


--
Ian Sturdy
sturdy...@mail.wlu.edu

From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on 
behalf of Albert Y. C. Lai [tre...@vex.net]
Sent: Tuesday, November 20, 2012 12:47 PM
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Compilers: Why do we need a core language?

On 12-11-20 06:54 AM, c...@lavabit.com wrote:

> I know nothing about compilers and interpreters. I checked several
> books, but none of them explained why we have to translate a
> high-level language into a small (core) language. Is it impossible
> (very hard) to directly translate high-level language into machine
> code?

Let the overall distance be fixed. More steps over that same distance
means each step is smaller, easier to design, easier to understand,
easier to correct if there are mistakes.

Forget code generation. Just parse and validate and then discard.
Already there are like 4 steps. Translate character sequence into token
sequence. Translate token sequence into grammar tree, while checking
grammar. Translate grammar tree into declaration groups, identifier
lookup tables, etc., while checking whether every used identifier is
declared or imported. Translate those groups and tables into
type-annotated groups and tables, while checking types.

Whew! After 4 steps of translating this to that, we still haven't
reached the core language! Why?

Because... have you ever tried to write a type-checker for character
sequence?

I'm sure some mad genius can do it, but I don't want to be that mad genius.

___
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] Compilers: Why do we need a core language?

[Albert Y. C. Lai]

On 12-11-20 06:54 AM, c...@lavabit.com wrote:


I know nothing about compilers and interpreters. I checked several
books, but none of them explained why we have to translate a
high-level language into a small (core) language. Is it impossible
(very hard) to directly translate high-level language into machine
code?


Let the overall distance be fixed. More steps over that same distance 
means each step is smaller, easier to design, easier to understand, 
easier to correct if there are mistakes.


Forget code generation. Just parse and validate and then discard. 
Already there are like 4 steps. Translate character sequence into token 
sequence. Translate token sequence into grammar tree, while checking 
grammar. Translate grammar tree into declaration groups, identifier 
lookup tables, etc., while checking whether every used identifier is 
declared or imported. Translate those groups and tables into 
type-annotated groups and tables, while checking types.


Whew! After 4 steps of translating this to that, we still haven't 
reached the core language! Why?


Because... have you ever tried to write a type-checker for character 
sequence?


I'm sure some mad genius can do it, but I don't want to be that mad genius.

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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Kim-Ee Yeoh]

> Is it impossible (very hard) to directly translate high-level language
into machine code?

There's a context to your question I don't understand, so let me ask:

Wouldn't it be easier to break a big step into smaller baby steps?
And if it's indeed easier why wouldn't you choose that route?

-- Kim-Ee


On Tue, Nov 20, 2012 at 6:54 PM,  wrote:

> Hello,
>
> I know nothing about compilers and interpreters. I checked several
> books, but none of them explained why we have to translate a
> high-level language into a small (core) language. Is it impossible
> (very hard) to directly translate high-level language into machine
> code?
>
>
>
>
> ___
> 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] Compilers: Why do we need a core language?

[Brandon Allbery]

On Tue, Nov 20, 2012 at 6:54 AM,  wrote:

> I know nothing about compilers and interpreters. I checked several
> books, but none of them explained why we have to translate a
> high-level language into a small (core) language. Is it impossible
> (very hard) to directly translate high-level language into machine
> code?
>

You might note that gcc does the same thing internally; its core seems to
be inspired by S-expressions.  (It's also somewhat lower level than GHC's
core, but then C is itself lower level.)

As for why:

* It's a way to remove redundancy and simplify implementation.
* Sometimes it's easier to rephrase a language feature in terms of another
similar feature, instead of duplicating code or making that code
sufficiently reusable to apply easily in multiple not-quite-identical
places.
* Sometimes it's because the language definition specifies a translation
that describes the behavior of a language feature (see, for example, do
blocks and automatically derived typeclasses in Haskell) and the simplest
way to ensure compliance with the standard is to do the same translation in
the compiler.
* It can also be easier to apply high level optimization techniques; if you
go straight from the highest level code to the lowest level, you are likely
to miss optimization opportunities that are only revealed (or only sanely
implementable) at intermediate levels.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[Joachim Breitner]

Hi,

Am Dienstag, den 20.11.2012, 06:54 -0500 schrieb c...@lavabit.com:
> I know nothing about compilers and interpreters. I checked several
> books, but none of them explained why we have to translate a
> high-level language into a small (core) language. Is it impossible
> (very hard) to directly translate high-level language into machine
> code?

I would expect that even if you were to implement a compiler for full
Haskell itself, you would end up generating a core language. E.g, where
clauses can be implemented using let. So after you have implemented let
you are likely to not copy the code but rather transform your where
clause into a let clause. And alas, you suddenly have introduced a core
language (Haskell without where clauses). This way you will end up with
a very reduced subset of Haskell.

Then you might also notice that some features are similar to implement
and you can merge the code if you add some feature to your language,
making it a bit more expressive. Then your core language will be more
than just a subset of Haskell.

As you can see, you will have a hard time preventing yourself from
introducing a core language.

Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: m...@joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nome...@joachim-breitner.de


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[AUGER Cédric]

Le Tue, 20 Nov 2012 10:49:01 -0500 (EST),
c...@lavabit.com a écrit :

> > What would be the point in doing so?
> 
> Well, I don't know. Would it save some time? Why bother with a core
> language?

The compilation process might be slightly faster, but I guess it
wouldn't be much noticeable.

Also I guess having a core language eases porting to new architectures,
you "just" have to port a simple core language rather than porting a
complex language.

The semantics of the core language is also rather simple, so you can
use it to explain and understand how it works, then for the high level
part, you can give a semantics by compilation to the core language.

Finally, adding a new feature seems easier and less error prone if you
have to translate it into the core language rather than compiling it
directly.

I never studied the Haskell compiler so I do not know the details, but
I think that having a core language is a good idea.

It is also good to have some VM to porting purposes.
If you have N source languages and M target machines, by providing N+M
stuff, you get N×M compilers !

> 
> 
> 
> ___
> 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] Compilers: Why do we need a core language?

[citb]

> What would be the point in doing so?

Well, I don't know. Would it save some time? Why bother with a core language?



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

Re: [Haskell-cafe] Compilers: Why do we need a core language?

[AUGER Cédric]

Le Tue, 20 Nov 2012 06:54:25 -0500 (EST),
c...@lavabit.com a écrit :

> Hello,
> 
> I know nothing about compilers and interpreters. I checked several
> books, but none of them explained why we have to translate a
> high-level language into a small (core) language. Is it impossible
> (very hard) to directly translate high-level language into machine
> code?

What would be the point in doing so?

> 
> 
> 
> 
> ___
> 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] Compilers: Why do we need a core language?

[José Lopes]

Hey,

Here are some interesting links you that might help answer your question.

http://www.aosabook.org/en/ghc.html
http://www.youtube.com/watch?v=7NPBrWDzO2A

Regards,
José

On 11/20/2012 12:54 PM, c...@lavabit.com wrote:

Hello,

I know nothing about compilers and interpreters. I checked several
books, but none of them explained why we have to translate a
high-level language into a small (core) language. Is it impossible
(very hard) to directly translate high-level language into machine
code?




___
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] Compilers

[Gwern Branwen]

On Sat, Nov 29, 2008 at 8:02 PM, John Meacham  wrote:
> On Sat, Nov 29, 2008 at 11:41:03PM +0100, Daniel Fischer wrote:
>> Great, nothing I don't already have, so download the source tarball, unpack
>> and
>> ./configure --prefix=$HOME
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> ... more configure output ...
>> checking for drift-ghc... no
>> configure: error:  DrIFT not found get it from
>> http://repetae.net/computer/haskell/DrIFT/
>>
>> Huh?
>> da...@linux:~/jhc/jhc-0.5.20080307> which DrIFT
>> /home/dafis/.cabal/bin/DrIFT
>> da...@linux:~/jhc/jhc-0.5.20080307> DrIFT --version
>> Version DrIFT-2.2.3
>
> Oh golly. I never put DrIFT on cabal, apparently whomever tried to
> cabalize it didn't include the ghc driver script, and also appeared to
> just drop the documentation from the package altogether. It is things
> like that that make it very hard to get behind cabal, why was DrIFT
> crippled just so it can be put on cabal? If cabal wasn't powerful enough
> to compile DrIFT, and we already had a perfectly good way of compiling
> it, why the need to shoehorn it in and cause this problem? sigh.
...
>        John

Thought I'd mention that
http://hackage.haskell.org/package/DrIFT-cabalized 2.2.3.1 includes a
drift-ghc.hs (compiles to /home/gwern/bin/bin/DrIFT-cabalized-ghc)
which is a clone of the drift-ghc.in shell script you allude to:

import Data.List (isInfixOf)
import System.Cmd (rawSystem)
import System.Environment (getArgs)
import System.Exit (ExitCode(ExitSuccess))
import Paths_DrIFT_cabalized  (getBinDir)

main :: IO ExitCode
main = do args <- getArgs
  case args of
(a:b:c:[]) -> conditional a b c
_ -> error "This is a driver script allowing DrIFT to be
used seamlessly with ghc.\n \
   \ in order to use it, pass '-pgmF drift-ghc -F'
to ghc when compiling your programs."

conditional ::  FilePath -> FilePath -> FilePath -> IO ExitCode
conditional orgnl inf outf = do prefix <- getBinDir
infile <- readFile inf
if "{-!" `isInfixOf` infile then do
putStrLn (prefix ++ "DriFT-cabalized " ++

   inf ++ " -o " ++ outf)

rawSystem inf ["-o", outf]
 else do writeFile outf ("{-# LINE 1
\"" ++ orgnl ++ " #-}")
 readFile inf >>= appendFile outf
 return ExitSuccess
{- GHC docs say: "-pgmF cmd
   Use cmd as the pre-processor (with -F only).
Use -pgmF cmd  to select the program to use as the preprocessor.
When invoked, the cmd pre-processor is given at least three arguments
on its command-line:
1. the first argument is the name of the original source file,
2. the second is the name of the file holding the input
3. third is the name of the file where cmd should write its output to." -}

John: I would appreciate you pointing out if I have made a mistake
anywhere in that and not actually replicated the functionality of the
shell script. (I think I have, but I didn't really understand what the
first echo was supposed to do and just copied its functionality.)

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

Re: [Haskell-cafe] Compilers

[Jules Bean]

John Meacham wrote:

I never was opposed to a cabal 'target' for jhc. I have 'make dist'
'make dist-rpm' and hopefully 'make msi' soon, adding a 'make
dist-hackage' alongside is not a bad thing, however, it is if it
complicates the standard build or comes to dominate development effort
or can't be done without duplication of functionality.


My understanding is that you can have a .cabal file which merely 
specifies the dependency information and metadata, but delegates all the 
actual building to your existing configure and make infrastructure.


It could then be entirely ignored (by someone who chose to type 
./configure && make) but it would still work for someone who wanted to 
use cabal (using the metadata to get any dependencies, and then 
thereafter using the make-based build).


Is this not a good path for a project like JHC?

Jules

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

Re: [Haskell-cafe] Compilers

[Jules Bean]

John Meacham wrote:

I never was opposed to a cabal 'target' for jhc. I have 'make dist'
'make dist-rpm' and hopefully 'make msi' soon, adding a 'make
dist-hackage' alongside is not a bad thing, however, it is if it
complicates the standard build or comes to dominate development effort
or can't be done without duplication of functionality.


My understanding is that you can have a .cabal file which merely 
specifies the dependency information and metadata, but delegates all the 
actual building to your existing configure and make infrastructure.


It could then be entirely ignored (by someone who chose to type 
./configure && make) but it would still work for someone who wanted to 
use cabal (using the metadata to get any dependencies, and then 
thereafter using the make-based build).


Is this not a good path for a project like JHC?

Jules

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

Re: [Haskell-cafe] Compilers

[John Meacham]

On Mon, Dec 01, 2008 at 01:02:40AM +, Ross Paterson wrote:
> I am also willing to remove any release with an unchanged name and
> made without the support of the maintainer.  You have made clear that
> the DrIFT-2.2.3 upload is in that category, so I have now removed it.
> Looking through, the only other package I spotted that might be such
> is HsASA-0.1 -- please let me know about this one, and any others
> I've missed.

No, that one is fine. I don't have any issues with my haskell _libraries_
being packaged up if done properly. Cabal has signifigantly more
utility for libraries than programs so the scales tip in its direction
more often then. Speaking of which, it would be nice if they were
seperated into two different sections on hackage. A few projects that
have both library and programs would be listed in both categories.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Ross Paterson]

On Sun, Nov 30, 2008 at 08:50:51AM -0800, John Meacham wrote:
> And creating a crippled version of something you wrote and passing it
> off as the original, in a way that clearly breaks things for other
> people definitely is something to get upset about.

There was a discussion of this issue on the libraries list in June/July,
resulting in an agreed policy being added to the hackage upload page,
including:

If a package is being maintained, any release not approved and
supported by the maintainer should use a different package name.

I am also willing to remove any release with an unchanged name and
made without the support of the maintainer.  You have made clear that
the DrIFT-2.2.3 upload is in that category, so I have now removed it.
Looking through, the only other package I spotted that might be such
is HsASA-0.1 -- please let me know about this one, and any others
I've missed.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Don Stewart]

john:
> On Sat, Nov 29, 2008 at 09:00:48PM -0500, Brandon S. Allbery KF8NH wrote:
> > On 2008 Nov 29, at 20:02, John Meacham wrote:
> >> Oh golly. I never put DrIFT on cabal, apparently whomever tried to
> >> cabalize it didn't include the ghc driver script, and also appeared to
> >> just drop the documentation from the package altogether. It is things
> >> like that that make it very hard to get behind cabal, why was DrIFT
> >> crippled just so it can be put on cabal? If cabal wasn't powerful  
> >> enough
> >> to compile DrIFT, and we already had a perfectly good way of compiling
> >> it, why the need to shoehorn it in and cause this problem? sigh.
> >
> >
> > Blaming Cabal for Audrey doing a quick-and-dirty translation (because  
> > she didn't have a whole lot of time to spend online and wasn't really  
> > familiar with Cabal or Hackage) is just digging for excuses.
> 
> Hmm? This wasn't done by Audrey, all the hackage/cabal stuff she has
> done for my projects has been with my blessing. (and thanks)
> 
> And creating a crippled version of something you wrote and passing it
> off as the original, in a way that clearly breaks things for other
> people definitely is something to get upset about. And no, that is not a
> technical problem with cabal itself, but it does make me worry about the
> motivations of some in the project when that sort of breakage seemed
> like a good idea to someone.

Looks like it was packaged by gwern when he was trawling the archives
finding releases that weren't on Hackage -- and yes, several of the
things he uploaded were incorrectly packages in some way or another. 

If I grab drift from Hackage though,

$ cabal install drift

Resolving dependencies...
Configuring DrIFT-2.2.3...
Preprocessing executables for DrIFT-2.2.3...
Building DrIFT-2.2.3...
Linking dist/build/DrIFT/DrIFT ...
Installing executable(s) in /home/dons/.cabal/bin

And it runs well enough for the other projects I've used it on.

$ DrIFT -V
Version DrIFT-2.2.3

Is the cabal distribution just missing extra scripts? There's a fine
line between "packaging" in the distro sense, that cabal does (where
only metadata is added), and an actual fork. In this case, it looks like
only metadata was added, so it's no different to any number of distro
packages.

Are you interested in ensuring the cabal file accurately describes the
package as you wish it to be installed?

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

Re: [Haskell-cafe] Compilers

[Eric Kow]

On Sun, Nov 30, 2008 at 17:45:55 +0100, Daniel Fischer wrote:
> I am now a proud owner of darcs-2.1.2, the source distribution built without 
> problems :), make test said "All tests successful!" three times :D
> Sorry to deprive you of the pleasure of helping.

:-)

> >   darcs failed:  Can't understand repository format: hashed
> >   darcs failed:  Can't understand repository format: darcs-2
> 
> I've always found darcs' predictive powers somewhat lacking.
> Seriously, it might be a good idea to have an error message like

This was just a bug in darcs.  The feature has been there for a while,
but was not sufficiently well tested.  Anyway, it's been fixed since
May.
 
> darcs failed: Can't understand repository format, may be new format or broken.

I think we would welcome some kind of patch to rephrase the messages
above to hint that that the reason it could not understand these
format elements was because they may be new.

> > Upgrade! Binary versions should be available shortly, either from your
> > favourite package distributor or by third party contributors.
> 
> Please, do not drop source distributions anyone, binaries tend to work on a 
> much smaller set of systems, source can build against more library versions.

The darcs team will always release a source tarball on its releases
(the next one scheduled for mid January)

Cheers,

-- 
Eric Kow 
PGP Key ID: 08AC04F9


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

Re: [Haskell-cafe] Compilers

[John Meacham]

On Sat, Nov 29, 2008 at 09:00:48PM -0500, Brandon S. Allbery KF8NH wrote:
> On 2008 Nov 29, at 20:02, John Meacham wrote:
>> Oh golly. I never put DrIFT on cabal, apparently whomever tried to
>> cabalize it didn't include the ghc driver script, and also appeared to
>> just drop the documentation from the package altogether. It is things
>> like that that make it very hard to get behind cabal, why was DrIFT
>> crippled just so it can be put on cabal? If cabal wasn't powerful  
>> enough
>> to compile DrIFT, and we already had a perfectly good way of compiling
>> it, why the need to shoehorn it in and cause this problem? sigh.
>
>
> Blaming Cabal for Audrey doing a quick-and-dirty translation (because  
> she didn't have a whole lot of time to spend online and wasn't really  
> familiar with Cabal or Hackage) is just digging for excuses.

Hmm? This wasn't done by Audrey, all the hackage/cabal stuff she has
done for my projects has been with my blessing. (and thanks)

And creating a crippled version of something you wrote and passing it
off as the original, in a way that clearly breaks things for other
people definitely is something to get upset about. And no, that is not a
technical problem with cabal itself, but it does make me worry about the
motivations of some in the project when that sort of breakage seemed
like a good idea to someone.

John


-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[John Meacham]

On Sat, Nov 29, 2008 at 05:10:24PM -0800, Don Stewart wrote:
> > Oh golly. I never put DrIFT on cabal, apparently whomever tried to
> > cabalize it didn't include the ghc driver script, and also appeared to
> > just drop the documentation from the package altogether. It is things
> > like that that make it very hard to get behind cabal, why was DrIFT
> > crippled just so it can be put on cabal? If cabal wasn't powerful enough
> > to compile DrIFT, and we already had a perfectly good way of compiling
> > it, why the need to shoehorn it in and cause this problem? sigh.
> 
> Sounds like a problem with the packaging of DrIFT for Hackage, not with
> Cabal per se. This can happen if the package author doesn't do the
> conversion from ad-hoc make systems to cabal -- metadata that was
> implicit in autoconf+make can be lost.
  

This is indicative of problems with some factions of the cabal community
in general though. That somehow the idea of getting a package into cabal
was more important than the package actually working.  Like it or not,
the cabal project has accumulated some supporters who have an agenda
where promoting cabal is more important than the actual value of cabal
to a project. This has made for a very hostile enviornment to be a
developer in.

> Perhaps the DrIFT maintainer could package it correctly, so that it can
> be used with the ~1000 other libraries on Hackage.

DrIFT is maintained by me and already can be used with the ~1000 other
libraries on hackage.


John


-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Daniel Fischer]

Am Sonntag, 30. November 2008 15:57 schrieb Eric Kow:
> Hi Daniel,
>
> On Sun, Nov 30, 2008 at 08:31:15 -0500, [EMAIL PROTECTED] 
wrote:
> > [EMAIL PROTECTED]:~/lhc> darcs get --partial http://code.haskell.org/lhc
> > Invalid repository:  http://code.haskell.org/lhc
> >
> > darcs failed:  failed to fetch:
> > http://code.haskell.org/lhc/_darcs/inventory ExitFailure 1
> >
> > There's a hashed_inventory in lhc/_darcs, but no inventory.
> > Is that a darcs2 vs. darcs1 incompatibility and I'm just screwed or is
> > the repo broken?
>
> There are two issues here.  One is that the LHC repository is indeed a
> darcs 2 repository

Yes, and as Austin told me, it was updated to darcs-2 format yesterday or the 
day before (depending on time-zone), so one might just consider it bad 
timing, except

> and you appear to have darcs 1 on your machine.  I
> think upgrading to darcs 2 would be a very good idea, and I'm sure the
> darcs community would be happy to help you with this.

I am now a proud owner of darcs-2.1.2, the source distribution built without 
problems :), make test said "All tests successful!" three times :D
Sorry to deprive you of the pleasure of helping.

I had problems with a darcs-2 prerelease earlier, that's why I was pessimistic 
about getting darcs-2 to work on my old system, the binary wouldn't work 
because it needed newer libs than I have (and updating those would wreak 
havoc on other components), and the one from the darcs repo needed a newer 
autoconf than I have, yay for source releases.
>
> The second issue is that our forward-compatibility detector was likely
> buggy in darcs 1.0.9.  The response darcs 1.0.9 should have given you
> was something like this:
>
>   darcs failed:  Can't understand repository format: hashed
>   darcs failed:  Can't understand repository format: darcs-2

I've always found darcs' predictive powers somewhat lacking.
Seriously, it might be a good idea to have an error message like

darcs failed: Can't understand repository format, may be new format or broken.

because that would give a starting point for resolving the problem (darcs-2 
was conspicuous enough here that I thought of that possibility, but maybe 
darcs users not suscribed to the relevant lists wouldn't).
>
> Unfortunately, the relationship between hashed and darcs 2 repositories
> is slightly confusing.  Basically you need a darcs 2 client if you see
> hashed_inventory, but it does not necessarily mean there is an
> incompatibility.  I hope that the following snippet from the darcs 2.1.0
> release announcement can help clear this up:
>
> What should I do?
> -
> Upgrade! Binary versions should be available shortly, either from your
> favourite package distributor or by third party contributors.

Please, do not drop source distributions anyone, binaries tend to work on a 
much smaller set of systems, source can build against more library versions.

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

Re: [Haskell-cafe] Compilers

[Eric Kow]

Hi Daniel,

On Sun, Nov 30, 2008 at 08:31:15 -0500, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED]:~/lhc> darcs get --partial http://code.haskell.org/lhc
> Invalid repository:  http://code.haskell.org/lhc
> 
> darcs failed:  failed to fetch: http://code.haskell.org/lhc/_darcs/inventory 
> ExitFailure 1
> 
> There's a hashed_inventory in lhc/_darcs, but no inventory.
> Is that a darcs2 vs. darcs1 incompatibility and I'm just screwed or is the 
> repo broken?

There are two issues here.  One is that the LHC repository is indeed a
darcs 2 repository and you appear to have darcs 1 on your machine.  I
think upgrading to darcs 2 would be a very good idea, and I'm sure the
darcs community would be happy to help you with this.

The second issue is that our forward-compatibility detector was likely
buggy in darcs 1.0.9.  The response darcs 1.0.9 should have given you
was something like this:

  darcs failed:  Can't understand repository format: hashed
  darcs failed:  Can't understand repository format: darcs-2

Unfortunately, the relationship between hashed and darcs 2 repositories
is slightly confusing.  Basically you need a darcs 2 client if you see
hashed_inventory, but it does not necessarily mean there is an
incompatibility.  I hope that the following snippet from the darcs 2.1.0
release announcement can help clear this up:

What should I do?
-
Upgrade! Binary versions should be available shortly, either from your
favourite package distributor or by third party contributors.

Other than installing the new darcs, no action is required on your part to
perform this upgrade. Darcs 2, including this particular version, is 100%
compatible with your pre-existing repositories.

If you have not done so already, you should consider using the hashed
repository format in place of your current old-fashioned repositories.
This format offers greater protection against accidental corruption,
better support for case insensitive file systems. It also provides some
very nice performance features, including lazy fetching of patches and a
global cache (both optional).

If darcs 1 compatibility is not a concern, you could also upgrade your
repositories all the way to the darcs 2 format. In addition to the
robustness and performance features above, this gives you the improved
merging semantics and conflicts handling that give darcs 2 its name.

More details about upgrading to darcs 2 here:
http://wiki.darcs.net/index.html/DarcsTwo

Another clarification
-
To be clear, we say that hashed repositories are backward-compatible.
This means that darcs 2 clients can pull and push patches between
them and old-fashioned repostiories.  On the other hand, interacting
with the hashed repositories themselves requires a darcs 2 client.

Thanks!

-- 
Eric Kow 
PGP Key ID: 08AC04F9


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

Re: [Haskell-cafe] Compilers

[Brandon S. Allbery KF8NH]

On 2008 Nov 29, at 20:02, John Meacham wrote:

Oh golly. I never put DrIFT on cabal, apparently whomever tried to
cabalize it didn't include the ghc driver script, and also appeared to
just drop the documentation from the package altogether. It is things
like that that make it very hard to get behind cabal, why was DrIFT
crippled just so it can be put on cabal? If cabal wasn't powerful  
enough

to compile DrIFT, and we already had a perfectly good way of compiling
it, why the need to shoehorn it in and cause this problem? sigh.



Blaming Cabal for Audrey doing a quick-and-dirty translation (because  
she didn't have a whole lot of time to spend online and wasn't really  
familiar with Cabal or Hackage) is just digging for excuses.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Compilers

[Daniel Fischer]

Am Sonntag, 30. November 2008 00:17 schrieb Austin Seipp:
>
> If you would be so kind as to try the latest lhc instead by running:
>
> $ cabal install lhc-0.6.20081127
>
> And reporting back, I would like to hear the results and if it went
> well. :)

Got and installed a lot of dependencies and the latest and greatest lhc in 20 
minutes (may have been 21, I didn't time it with a stop-watch) again :)

>
> > Unfortunately:
> > $ lhc -o lhcHeap heapMain
> > lhc: user error (LibraryMap: Library base not found!)
> >
> > Oops.
>
> There is a reason this is happening, and there isn't an easy way to
> get around it right now, it seems.
>
> The problem is that when you just install lhc, it has no libraries. To
> install the base library, you are going to need a copy of the lhc
> source code - this cannot be automated by hackage.
>
> Why? Because we are afraid that by uploading lhc's version of base -
> simply called 'base' - to hackage, will will inadvertantly stop every
> continually uploaded package from building, and cabal install could
> stop working too. Scary thought, huh? :)

Fair enough. Might be good to advertise that on Hackage, though.

>
> The easiest way to fix this problem is by doing the following:
>
> 1. You probably want the darcs version of LHC anyway if you're willing
>to try it. Good improvements are being made pretty much every day.
> 2. After you get the darcs repository, just go into it and do 'cabal
>install'

[EMAIL PROTECTED]:~/lhc> darcs get --partial http://code.haskell.org/lhc
Invalid repository:  http://code.haskell.org/lhc

darcs failed:  failed to fetch: http://code.haskell.org/lhc/_darcs/inventory 
ExitFailure 1

There's a hashed_inventory in lhc/_darcs, but no inventory.
Is that a darcs2 vs. darcs1 incompatibility and I'm just screwed or is the 
repo broken?

> 3. To install base, you are probably going to want the latest versions
>of both cabal and cabal-install from the darcs repository - they
>include support for LHC already (cabal 1.7.x.)

Okay, done. Though for some reason cabal --version says 
cabal-install version 0.6.0
using version 1.6.0.1 of the Cabal library

even though I changed the constraint to Cabal >= 1.7 in the 
cabal-install.cabal file?

> 4. After you've installed lhc and the latest cabal/cabal install, you
>can just do:
>$ cd lhc/lib/base
>$ cabal install --lhc
>
>And it should Just Work.

Will try if I can darcs get the repo :-/

>
> All of these instructions can be found here:
>
> http://lhc.seize.it/#development
>
> Don Stewart just brought up this point in #haskell, so I think I will
> modify the wiki page a bit (http://lhc.seize.it) and highlight these
> notes and why it's currently like this.
>
> I apologize for it being so cumbersome right now. We're trying to
> figure out a good solution.
>
> > Okay, ./configure --help and searching through the configure script
> > (which I completely don't know the syntax of) lead me to try
> > ./configure --prefix=$HOME DRIFTGHC=/home/dafis/.cabal/bin/DrIFT
> > which successsfully completes the configure step, but shouldn't configure
> > find executables in the path?
>
> The reason is because the configure.ac script is designed to search
> for an executable named 'drift-ghc', not 'DrIFT'. I have no idea why.
>
> > import System (getArgs). Now
> > ... myriads of lines of output ...
> > jhc: user error (Grin.FromE - Unknown primitive: ("eqRef__",[EVar
> > (::ELit (Data.IORef.Ref__ (ELit ([EMAIL PROTECTED]::ESort *))::ESort
> > #)),EVar (6670::ELit (Data.IORef.Ref__ (ELit ([EMAIL PROTECTED]::ESort
> > *))::ESort #))]))
> >
> > What?
> > And I get the same error for every nontrivial programme I tried to
> > compile, but not for a couple of trivial programmes.
>
> LHC and JHC are still extremely incomplete. They're nowhere near as
> supportive of extensions or libraries as GHC is. Don't count on them
> compiling anything non-trivial just yet.

No extensions and libraries, just a bit of Haskell98, the implicit heap from 
http://www.haskell.org/haskellwiki/Primes with a main that prints the n-th 
prime. I wouldn't expect many extensions yet, but most of H98.

>
> Austin

Cheers,
Daniel

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

Re: [Haskell-cafe] Compilers

[Don Stewart]

john:
> On Sat, Nov 29, 2008 at 11:41:03PM +0100, Daniel Fischer wrote:
> > Great, nothing I don't already have, so download the source tarball, unpack 
> > and
> > ./configure --prefix=$HOME
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > ... more configure output ...
> > checking for drift-ghc... no
> > configure: error:  DrIFT not found get it from 
> > http://repetae.net/computer/haskell/DrIFT/
> > 
> > Huh?
> > [EMAIL PROTECTED]:~/jhc/jhc-0.5.20080307> which DrIFT
> > /home/dafis/.cabal/bin/DrIFT
> > [EMAIL PROTECTED]:~/jhc/jhc-0.5.20080307> DrIFT --version
> > Version DrIFT-2.2.3
> 
> Oh golly. I never put DrIFT on cabal, apparently whomever tried to
> cabalize it didn't include the ghc driver script, and also appeared to
> just drop the documentation from the package altogether. It is things
> like that that make it very hard to get behind cabal, why was DrIFT
> crippled just so it can be put on cabal? If cabal wasn't powerful enough
> to compile DrIFT, and we already had a perfectly good way of compiling
> it, why the need to shoehorn it in and cause this problem? sigh.

Sounds like a problem with the packaging of DrIFT for Hackage, not with
Cabal per se. This can happen if the package author doesn't do the
conversion from ad-hoc make systems to cabal -- metadata that was
implicit in autoconf+make can be lost.

Perhaps the DrIFT maintainer could package it correctly, so that it can
be used with the ~1000 other libraries on Hackage.

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

Re: [Haskell-cafe] Compilers

[John Meacham]

On Sat, Nov 29, 2008 at 11:41:03PM +0100, Daniel Fischer wrote:
> Great, nothing I don't already have, so download the source tarball, unpack 
> and
> ./configure --prefix=$HOME
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> ... more configure output ...
> checking for drift-ghc... no
> configure: error:  DrIFT not found get it from 
> http://repetae.net/computer/haskell/DrIFT/
> 
> Huh?
> [EMAIL PROTECTED]:~/jhc/jhc-0.5.20080307> which DrIFT
> /home/dafis/.cabal/bin/DrIFT
> [EMAIL PROTECTED]:~/jhc/jhc-0.5.20080307> DrIFT --version
> Version DrIFT-2.2.3

Oh golly. I never put DrIFT on cabal, apparently whomever tried to
cabalize it didn't include the ghc driver script, and also appeared to
just drop the documentation from the package altogether. It is things
like that that make it very hard to get behind cabal, why was DrIFT
crippled just so it can be put on cabal? If cabal wasn't powerful enough
to compile DrIFT, and we already had a perfectly good way of compiling
it, why the need to shoehorn it in and cause this problem? sigh.


Incidentally, the jhc tarball no longer needs drift to compile (you only
need it if you compile from the darcs repo directly) so I'll get rid of that
check.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Don Stewart]

bulat.ziganshin:
> Hello Daniel,
> 
> Sunday, November 30, 2008, 1:41:03 AM, you wrote:
> 
> > Yes, that's very nice to be able to just type
> > $ cabal update
> > $ cabal install whatever
> > and cabal automatically takes care of dependencies (unfortunately only 
> > Haskell
> 
> i have to mention that there are no haskell compilers that work this
> way. may be this say something important about Cabal? ;)

Though there's a perl compiler,

$ cabal install pugs

Enjoy!

-- Don (who thinks we need less talk, more action)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Austin Seipp]

Hi Daniel,

> 1. cabal install lhc
> 20 minutes later I have an lhc executable installed (and the graphviz 
> package), great, can't be any simpler.

Awesome! Glad it worked for you.

A tidbit: unfortunately, due to a mistake in the first upload of lhc,
you will need to provide an exact version if you want the latest and
greatest.

The reason behind this is because when David uploaded lhc initially,
he gave it a version of '20081121'. After a few days of hacking the
source code, I decided to upload a new version - but I changed the
version number to 0.6.20081127 (it is 0.6 because jhc is currently at
0.5, and I see the improvements we made as worthy of a minor version
bump.)

So, as far as cabal is concerned, 20081121 > 0.6.20081127, so it will
by default install the older version.

If you would be so kind as to try the latest lhc instead by running:

$ cabal install lhc-0.6.20081127

And reporting back, I would like to hear the results and if it went
well. :)

> Unfortunately:
> $ lhc -o lhcHeap heapMain
> lhc: user error (LibraryMap: Library base not found!)
> 
> Oops.

There is a reason this is happening, and there isn't an easy way to
get around it right now, it seems.

The problem is that when you just install lhc, it has no libraries. To
install the base library, you are going to need a copy of the lhc
source code - this cannot be automated by hackage.

Why? Because we are afraid that by uploading lhc's version of base -
simply called 'base' - to hackage, will will inadvertantly stop every
continually uploaded package from building, and cabal install could
stop working too. Scary thought, huh? :)

The easiest way to fix this problem is by doing the following:

1. You probably want the darcs version of LHC anyway if you're willing
   to try it. Good improvements are being made pretty much every day.
2. After you get the darcs repository, just go into it and do 'cabal
   install'
3. To install base, you are probably going to want the latest versions
   of both cabal and cabal-install from the darcs repository - they
   include support for LHC already (cabal 1.7.x.)
4. After you've installed lhc and the latest cabal/cabal install, you
   can just do:
   $ cd lhc/lib/base
   $ cabal install --lhc

   And it should Just Work.

All of these instructions can be found here: 

http://lhc.seize.it/#development

Don Stewart just brought up this point in #haskell, so I think I will
modify the wiki page a bit (http://lhc.seize.it) and highlight these
notes and why it's currently like this.

I apologize for it being so cumbersome right now. We're trying to
figure out a good solution.

> Okay, ./configure --help and searching through the configure script (which I 
> completely don't know the syntax of) lead me to try 
> ./configure --prefix=$HOME DRIFTGHC=/home/dafis/.cabal/bin/DrIFT
> which successsfully completes the configure step, but shouldn't configure 
> find 
> executables in the path?

The reason is because the configure.ac script is designed to search
for an executable named 'drift-ghc', not 'DrIFT'. I have no idea why.

> import System (getArgs). Now
> ... myriads of lines of output ...
> jhc: user error (Grin.FromE - Unknown primitive: ("eqRef__",[EVar (::ELit 
> (Data.IORef.Ref__ (ELit ([EMAIL PROTECTED]::ESort *))::ESort #)),EVar 
> (6670::ELit 
> (Data.IORef.Ref__ (ELit ([EMAIL PROTECTED]::ESort *))::ESort #))]))
> 
> What? 
> And I get the same error for every nontrivial programme I tried to compile, 
> but not for a couple of trivial programmes.

LHC and JHC are still extremely incomplete. They're nowhere near as
supportive of extensions or libraries as GHC is. Don't count on them
compiling anything non-trivial just yet.

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

Re: [Haskell-cafe] Compilers

[Daniel Fischer]

Am Samstag, 29. November 2008 11:41 schrieb John Meacham:
> 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!

Yes, that's very nice to be able to just type
$ cabal update
$ cabal install whatever
and cabal automatically takes care of dependencies (unfortunately only Haskell 
dependencies, but hey, can't expect real magic), while the configure && make 
build system requires me to do it all myself (which becomes a real PITA when 
there are many dependencies not yet installed).

>
> 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 doubt a few dozen keystrokes make a difference to those who are willing to 
try out jhc, but chasing dependencies could make a difference. Fortunately 
jhc hasn't many, so I was ready to try both methods.

1. cabal install lhc
20 minutes later I have an lhc executable installed (and the graphviz 
package), great, can't be any simpler.
Unfortunately:
$ lhc -o lhcHeap heapMain
lhc: user error (LibraryMap: Library base not found!)

Oops.

2. grab jhc, configure && make
I need
ghc >= 6.8.2, yes, 6.8.3
DrIFT, yes, 2.2.3
binary, yes
zlib, yes

Great, nothing I don't already have, so download the source tarball, unpack 
and
./configure --prefix=$HOME
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
... more configure output ...
checking for drift-ghc... no
configure: error:  DrIFT not found get it from 
http://repetae.net/computer/haskell/DrIFT/

Huh?
[EMAIL PROTECTED]:~/jhc/jhc-0.5.20080307> which DrIFT
/home/dafis/.cabal/bin/DrIFT
[EMAIL PROTECTED]:~/jhc/jhc-0.5.20080307> DrIFT --version
Version DrIFT-2.2.3

Okay, ./configure --help and searching through the configure script (which I 
completely don't know the syntax of) lead me to try 
./configure --prefix=$HOME DRIFTGHC=/home/dafis/.cabal/bin/DrIFT
which successsfully completes the configure step, but shouldn't configure find 
executables in the path?
Now make. Lots of warnings, but doesn't fail.
make install, okay, ready to go.

helloWorld works, good, but dumps thousands of lines of output I don't want. 
How do I tell jhc to shut up, and why isn't that the default? 
Now something a bit harder, make me a couple of primes. First problem:
import System.Environment (getArgs)

Error: Module not found: System.Environment

Okay, different organisation of base package, mildly annoying, use
import System (getArgs). Now
... myriads of lines of output ...
jhc: user error (Grin.FromE - Unknown primitive: ("eqRef__",[EVar (::ELit 
(Data.IORef.Ref__ (ELit ([EMAIL PROTECTED]::ESort *))::ESort #)),EVar 
(6670::ELit 
(Data.IORef.Ref__ (ELit ([EMAIL PROTECTED]::ESort *))::ESort #))]))

What? 
And I get the same error for every nontrivial programme I tried to compile, 
but not for a couple of trivial programmes.

So I spent a few of hours to litter my hard disk with a completely useless 
broken lhc and a basically useless broken jhc :(

Conclusion:
the cabal package is much easier to install, but in this case the result of 
configure && make is marginally more useful.
However, neither produced a working compiler, so no cake.
Both systems suck when they fail.

Cheers,
Daniel


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

Re: [Haskell-cafe] Compilers

[Don Stewart]

duncan.coutts:
> > 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've sometimes wondered why nobody has made a generic configure.ac and
> makefile that wraps the Cabal build procedure. It seems pretty
> straightforward and it might help lower barriers for some users,
> especially, as John mentions, potential users from outside the
> community.

Yes. Reuse. That's why we moved to Cabal in the first place - to avoid
reimplementing Makefiles, .hi rules, .o rules, and ld linking arguments
once per Haskell library, which wasn't scalable in the slightest.

We could come back, and have the 'make && make install' fans wrap up
cabal with a generic wrapper for people who like to type 'make'.

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

Re: [Haskell-cafe] Compilers

[Duncan Coutts]

On Fri, 2008-11-28 at 19:30 -0800, John Meacham 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. 

In general John is right in most of his criticisms of Cabal. As someone
who works on Cabal I am well aware of the problems in its design and
implementation. I happen to think that most of the problems can be fixed
but it would be silly to suggest that the balance of advantages to
disadvantages goes in its favour for every project.

The advantages at the moment are greatest for small projects and are in
a large part due to network effects. The major problems are in the
configuration and build components. The configuration language is not
quite expressive enough and the current configuration search
implementation does not take advantage of the full expressiveness of the
existing language. The build component obviously should be based on a
dependency system, as make is, rather than IO () and ghc --make. There
are lots of things we don't do well because of this.

As I said, I think all these things are fixable. But it is a lot of
work. We're currently limited by the amount of developer time we have.
So I would like to encourage people to get involved. There are elegant
solutions to the problems. It's actually quite fun working on the new
bits and helping to drain the IO () swamp.

> 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've sometimes wondered why nobody has made a generic configure.ac and
makefile that wraps the Cabal build procedure. It seems pretty
straightforward and it might help lower barriers for some users,
especially, as John mentions, potential users from outside the
community.


Duncan

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

Re: [Haskell-cafe] Compilers

[John Meacham]

On Fri, Nov 28, 2008 at 08:51:45PM -0800, Jason Dagit wrote:
> On Fri, Nov 28, 2008 at 7:30 PM, John Meacham <[EMAIL PROTECTED]> wrote:
> > 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.

This always seemed like a rather weak argument, first of all, it's not
all that tricky to make autotools builds work on windows. Also, Windows
users by far prefer binary distributions anyway. They are downloading
the msi's rather than the source code. People who are actively
developing a project generally have a more advanced toolchain anyway.
Not that an easier windows build isn't useful, but that slightly easier
windows build is outweighed by the much more complicated build system
dependencies that are paid everywhere.


> 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.

This is sort of like splitting the baby, I don't think the effort is
really that small. A build system is a fairly complicated piece of code,
and it is also one of the parts I want more than anything to 'just work'
and having to worry about two different systems would not be productive.
A dumbed down build that is the intersection of both systems would be
barely usable and a drain on development effort.


I never was opposed to a cabal 'target' for jhc. I have 'make dist'
'make dist-rpm' and hopefully 'make msi' soon, adding a 'make
dist-hackage' alongside is not a bad thing, however, it is if it
complicates the standard build or comes to dominate development effort
or can't be done without duplication of functionality.

Cabal is not entirely conducive to being used in this way at the moment,
but this can be improved on. Some of the issues arn't too hard and
perhaps are being worked on, like adding a 'hackage release' field, and
a separate 'hackage' and 'project' maintainer fields. Others are
trickier, like the requirement to conform to hackages version numbering
policy that might differ from the native one. workarounds are possible
of course. But again, this is work. Even if the code isn't that much, it
does place a support burden on me and other jhc developers, so it isn't
something I'd do on a whim and without a clean design that does not
introduce any cabal dependencies on the standard build or require
ongoing support that is more than minimal, in fact, the
only time cabal should be invoked is specifically the case of installing
via cabal-install. 



> > 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.  

I totally agree.


> 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 

Re: [Haskell-cafe] Compilers

[Jason Dagit]

On Sat, Nov 29, 2008 at 2:41 AM, John Meacham <[EMAIL PROTECTED]> wrote:

> 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.


When it comes down to it, I've just been down a slippery slope.

The fact is, hackage works and hackage is a good reason to support cabal.

I'd also so say this thread is no longer productive.  A fork happened, the
fork embraces cabal but jhc does not need to embrace cabal; end of story
really.  We all get what we want.

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

Re: [Haskell-cafe] Compilers

[John Meacham]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Jason Dagit]

On Fri, Nov 28, 2008 at 7:30 PM, John Meacham <[EMAIL PROTECTED]> 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
for

Re: [Haskell-cafe] Compilers

[Don Stewart]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[John Meacham]

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 

Re: [Haskell-cafe] 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 +, 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.



PGP.sig
Description: Signierter Teil der Nachricht
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Don Stewart]

allbery:
> On 2008 Nov 26, at 16:58, Matthias Kilian wrote:
> >On Wed, Nov 26, 2008 at 09:35:01PM +, 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Brandon S. Allbery KF8NH]

On 2008 Nov 26, at 16:58, Matthias Kilian wrote:

On Wed, Nov 26, 2008 at 09:35:01PM +, 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] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Compilers

[Jason Dagit]

On Wed, Nov 26, 2008 at 6:19 PM, Richard O'Keefe <[EMAIL PROTECTED]> 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Richard O'Keefe]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Bernie Pope]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Josef Svenningsson]

On Wed, Nov 26, 2008 at 11:14 PM, David Menendez <[EMAIL PROTECTED]> 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[David Menendez]

On Wed, Nov 26, 2008 at 4:58 PM, Matthias Kilian <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 26, 2008 at 09:35:01PM +, 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 <[EMAIL PROTECTED]>

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

Re: [Haskell-cafe] Compilers

[Matthias Kilian]

On Wed, Nov 26, 2008 at 09:35:01PM +, 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[John Meacham]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Andrew Coppin]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Andrew Coppin]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Donnie Jones]

Hello Andrew,

On Wed, Nov 26, 2008 at 4:24 PM, Andrew Coppin
<[EMAIL PROTECTED]>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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Jake McArthur]

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



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe