[Haskell-cafe] Opinion about JHC
Philippos Apolinarius
1 --- One can cross-compile programs easily. For instance, here is how I generated code for Windows:
jhc --cross -mwin32 genetic.hs -o genetic
2 -- It seems to be quite complete.
3 -- However, it often compiles a file, but the program fails to run.
I have the following questions about it:
1 -- How active is the team who is writing the JHC compiler?
2 -- Is it complete Haskell? The author claims that it is; it compiled all programs that I wrote, but that does not mean much, because my programs are quite simple.
3 -- Why the Haskell community almost never talks about JHC?
__________________________________________________________________
The new Internet Explorer� 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
Thomas DuBuisson
The "Team" is John and Its not his day job afaik. Lemmih used to work
on it before he forked it into "LHC" which has since evolved into a
new (GRIN based) backend for GHC [1].
> 2 -- Is it complete Haskell? The author claims that it is; it compiled all programs that I wrote, but that does not mean much, because my programs are quite simple.
"Complete Haskell" has different meaning to different people. Perhaps
it is H98 with FFI and concurrency? Hopefully it supports some more
of the extentions.
> 3 -- Why the Haskell community almost never talks about JHC?
A) I suppose the lack of information wrt what extentions are supported
is one reason I avoid it. My previous experience with JHC was also
negative what with it not including/compiling necessary packages such
as bytestring.
B) I just installed it and ran it against a recent project:
"evcaCLI.hs:1 - Warning: The pragma 'LANGUAGE' is unknown". It then
failed to parse something futher on (unknown, poor error message...
perhaps a bang pattern).
C) Poor cabal integration, it would seem.
I know I saw a recent jhc-7.2 patch for cabal but for now I use cabal
1.6.0.3 and the --jhc option doesn't seem to work.
So these are mostly community issues with perhaps too much focus on a
single compiler ecosystem, but they are real issues none-the-less.
None of this is ment as a knock on JHC, which is cool but not yet of
use to me personally.
Thomas
[1] http://lhc.seize.it/
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
John Meacham
> I discovered a Haskell compiler that generates very small and fast
> code. In fact, it beats Clean. It has the following properties:
Excellent. that was my goal ;)
> 1 --- One can cross-compile programs easily. For instance, here is how I generated code for Windows:
>
> jhc --cross -mwin32 genetic.hs -o genetic
Yup. This was a major goal. compiling for iPhones and embedded arches is
just as easy assuming you have a gcc toolchain set up. (at least with
the hacked iPhone SDK.. I have never tried it with the official one)
>
> 2 -- It seems to be quite complete.
>
> 3 -- However, it often compiles a file, but the program fails to run.
>
> I have the following questions about it:
>
> 1 -- How active is the team who is writing the JHC compiler?
Hi, I am the main contributor, but others are welcome and several have
made signifigant contributions. Development tends to be spurty. A lot of
work will get done in a short amount of time, this generally corresponds
to when an external contributor gets involved and the back and forth
helps stimulate patches on my part to complement theirs.
Although I have not been able to devote a lot of my time to jhc in the
past, hopefully this will change in the not to distant future and I will
be able to work on it full time.
> 2 -- Is it complete Haskell? The author claims that it is; it compiled
> all programs that I wrote, but that does not mean much, because my
> programs are quite simple.
It does Haskell 98 and several extensions, which is pretty much what GHC
does. However, it does not implement the same set of extensions as GHC
so this causes issues as a lot of people use GHC extensions extensively.
I plan on supporting all of Haskell' of course, and the popular GHC
extensions to help compatibility. Not all are implemented.
> 3 -- Why the Haskell community almost never talks about JHC?
Part of it is that I am not very good at advocacy. I don't always
post announcements on the main haskell lists figuring the interested
parties are on the jhc list already. I do try to make jhc good, fast,
and usable, I always hoped someone better at advocacy than me would join
the project :) In truth, I think the spurty nature of development also
affects this, the list will be quite for a long time with a flurry of
development lasting a few weeks occasionally inspiring some discussion
in the other groups.
In any case, I am glad you liked what you found! please join the mailing
list for jhc if you are interested in its development or using it.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Philippos Apolinarius
I am trying JHC in a small embedded system (Medical instruments). The software is written in Clean, and I am translating to Haskell. You may want to take a look at my page:
I am writing because I found something in JHC that smells like a bug. The program compiles without a single complaint both in GHC and JHC, but the resulting binary file does not work in JHC. I wrote a simplified example so you can spot the problem easily. The original program is used to design and simplify digital circuits for sensors (capnograms, electrocardiograms, electroencephalograms, electromyograms, and temperature). It seems that JHC is not able to deal with the trees representing the circuits. Here is a very small program. All it does is to read a tree and show it:
{- file: tree.hs -}
{- compile: jhc tree.hs -dc -o jtree }
import System (getArgs)
import System.IO
import IO
data Op = AND | OR | NOT deriving (Show, Read)
data Tree= L Int | T Op [Tree] deriving (Show, Read)
main= do
putStrLn "Give me a tree:"
s <- getLine
let xx= read s
putStrLn (show (xx::Tree))
Here is what happens when I try to run it:
philip@desktop:~/jhctut$ ./jtree
Give me a tree:
T AND (L 1, L 2)
jtree_code.c:2670: case fell off
Aborted
It seems that the problem is in the Read class, since it works if I use the Show class only:
import System (getArgs)
import System.IO
import IO
data Op = AND | OR | NOT deriving (Show, Read)
data Tree= L Int | T Op [Tree] deriving (Show, Read)
main= do
putStrLn "Give me a tree:"
s <- getLine
let xx= T AND [L 1, L 2]
putStrLn (show (xx::Tree))
I hope you can fix it.
--- On Wed, 11/11/09, John Meacham <jo...@repetae.net> wrote:
John
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
Felipe Lessa
> data Op = AND | OR | NOT deriving (Show, Read)
Hmm, you see,
> philip@desktop:~/jhctut$ ./jtree
> Give me a tree:
> T AND (L 1, L 2)
>
> jtree_code.c:2670: case fell off
> Aborted
you declared 'T Op [Tree]' so you should give 'T AND [L 1, L 2]'
as the tree, right?
--
Felipe.
Philippos Apolinarius
> as the tree, right?
You are right. This means that I gave the correct input to the program. As you can see, I typed 'T AND [L 1, L 2]'. Therefore, JHC was expected to parse and print it. However, it failed to parse it. The program works perfectly well in GHC. Here is the GHC output:
> philip@desktop:~/jhctut$ ghc tree.hs --make
[1 of 1] Compiling Main������������ ( tree.hs, tree.o )
Linking tree ...
> philip@desktop:~/jhctut$ ./tree
Give me a tree:
T AND [L 1, L 2]
T AND [L 1,L 2]
--- On Wed, 11/11/09, Felipe Lessa <felipe...@gmail.com> wrote:
From: Felipe Lessa <felipe...@gmail.com>
Subject: Re: [Haskell-cafe] Problem with JHC
To: haskel...@haskell.org
Hmm, you see,
__________________________________________________________________
Make your browsing faster, safer, and easier with the new Internet Explorer� 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
Ross Mellgren
Here is what happens when I try to run it:
philip@desktop:~/jhctut$ ./jtree
Give me a tree:
T AND (L 1, L 2)
jtree_code.c:2670: case fell off
Aborted
You gave it parens not square brackets.
-Ross
> Get the name you've always wanted ! @ymail.com or
> @rocketmail.com._______________________________________________
Paolino
corrections to make it compile, which I don't think they are related to this
*bug*. Testing the given code, it aborts for every inputs I give it "L 1",
" T AND [L 1,L 2]" included.
I couldn't make it compile using function "reads" instead.
paolino
2009/11/11 Ross Mellgren <rmm-h...@z.odi.ac>
> According to the paste you gave for the JHC test run:
>
> Here is what happens when I try to run it:
>
> philip@desktop:~/jhctut$ ./jtree
> Give me a tree:
> T AND (L 1, L 2)
>
> jtree_code.c:2670: case fell off
> Aborted
>
> You gave it parens not square brackets.
>
> -Ross
>
> On Nov 11, 2009, at 11:45 AM, Philippos Apolinarius wrote:
>
> > you declared 'T Op [Tree]' so you should give 'T AND [L 1, L 2]'
> > as the tree, right?
> Hi, Felipe.
> You are right. This means that I gave the correct input to the program. As
> you can see, I typed 'T AND [L 1, L 2]'. Therefore, JHC was expected to
> parse and print it. However, it failed to parse it. The program works
> perfectly well in GHC. Here is the GHC output:
>
> > philip@desktop:~/jhctut$ ghc tree.hs --make
> [1 of 1] Compiling Main ( tree.hs, tree.o )
> Linking tree ...
> > philip@desktop:~/jhctut$ ./tree
> Give me a tree:
> T AND [L 1, L 2]
> T AND [L 1,L 2]
>
> --- On *Wed, 11/11/09, Felipe Lessa <felipe...@gmail.com>* wrote:
>
>
> From: Felipe Lessa <felipe...@gmail.com>
> Subject: Re: [Haskell-cafe] Problem with JHC
> To: haskel...@haskell.org
> Received: Wednesday, November 11, 2009, 6:23 AM
>
> On Wed, Nov 11, 2009 at 04:32:05AM -0800, Philippos Apolinarius wrote:
> > data Op = AND | OR | NOT deriving (Show, Read)
> > data Tree= L Int | T Op [Tree] deriving (Show, Read)
>
> Hmm, you see,
>
> > philip@desktop:~/jhctut$ ./jtree
> > Give me a tree:
> > T AND (L 1, L 2)
> >
> > jtree_code.c:2670: case fell off
> > Aborted
>
> you declared 'T Op [Tree]' so you should give 'T AND [L 1, L 2]'
> as the tree, right?
>
> --
> Felipe.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskel...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> ------------------------------
> Get the name you've always wanted <http://ca.promos.yahoo.com/jacko/>! *@
> ymail.com *or *@rocketmail.com*
> ._______________________________________________
Lennart Augustsson
Do you use jhc when you develop jhc? I.e., does it compile itself.
For me, this is the litmus test of when a compiler has become usable.
I mean, if even the developers of a compiler don't use it themselves,
why should anyone else? :)
-- Lennart
Donn Cave
> Do you use jhc when you develop jhc? I.e., does it compile itself.
> For me, this is the litmus test of when a compiler has become usable.
> I mean, if even the developers of a compiler don't use it themselves,
> why should anyone else? :)
Though that's exactly backwards for minority platforms, where the
compilers that compile themselves tend to be no use whatever.
Donn Cave, do...@avvanta.com
Lennart Augustsson
like some embedded systems, then I would have to agree.
-- Lennart
Donn Cave
> If by minority platform you mean platforms that are resource starved,
> like some embedded systems, then I would have to agree.
Like anything but the platform the compiler developer(s) use. If you
used a platform like that, you would certainly have to agree. If you
were a compiler developer for a language that supports like-platform
porting the way GHC does, after trying to keep that working while
developing the language I suspect you might also be tempted to agree.
Donn Cave, do...@avvanta.com
Philippos Apolinarius
Ops, the paste is wrong, but the bug is real. I mean, if I try to run
the program with the right input, the program aborts in the same place,
with the same error message:
philip@desktop:~/jhctut$ ./jtestarbo
Give me a tree:
T AND [L 1, L 2]
jtestarbo_code.c:2670: case fell off
Abortado
In fact, it aborts in the same place for any input. This fact may help to discover where the trouble is:
philip@desktop:~/jhctut$ ./jtestarbo
Give me a tree:
fdsfkldkl
jtestarbo_code.c:2670: case fell off
Abortado
--- On Wed, 11/11/09, Ross Mellgren <rmm-h...@z.odi.ac> wrote:
Hmm, you see,
__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
http://ca.toolbar.yahoo.com.
Philippos Apolinarius
I
am sending you this second email because the first one has a worng paste. However, if I use the right input, I gent the same error. In fact, it gives exactly the same error for any input, right or wrong.
{- file: tree.hs -}
{- compile: jhc tree.hs -dc -o
jtree }
import System (getArgs)
import System.IO
import IO
data Op = AND | OR | NOT deriving (Show, Read)
data Tree= L Int | T Op [Tree] deriving (Show, Read)
main= do
putStrLn "Give me a tree:"
s <- getLine
let xx= read s
putStrLn (show (xx::Tree))
Here is what happens when I try to run it:
philip@desktop:~/jhctut$ ./jtree
Give me a tree:
T AND [L 1, L 2]
jtree_code.c:2670: case fell off
Aborted
It gives the same error for any input:
philip@desktop:~/jhctut$ ./jtestarbo
Give me a tree:
fdsfkldkl
jtestarbo_code.c:2670: case fell off
Abortado
It seems that the problem is in the Read class, since it works if I use the Show class only:
import System (getArgs)
import System.IO
import IO
data Op = AND | OR | NOT deriving (Show, Read)
data Tree= L Int | T Op [Tree] deriving (Show, Read)
main= do
putStrLn "Give me a tree:"
s <-
getLine
let xx= T AND [L 1, L 2]
putStrLn (show (xx::Tree))
I hope you can fix it.
--- On Wed, 11/11/09, John Meacham <jo...@repetae.net> wrote:
From: John Meacham <jo...@repetae.net>
Subject: Re: [Haskell-cafe] Opinion about JHC
To: haskel...@haskell.org
John
__________________________________________________________________
Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com
Thomas DuBuisson
> data TreeX = Leaf Int | NotLeaf Int deriving (Show, Read)
��� [tommd@Mavlo Test]$ ./jtree
��� Give me a tree:
��� Leaf 5
��� jtree_code.c:2572: case fell off
��� Aborted
��� [tommd@Mavlo Test]$ ./jtree
��� Give me a tree:
��� NotLeaf
��� jtree_code.c:2572: case fell off
��� Aborted
So the read for that does not work... but surprisingly...
> data TreeX = Leaf Int | NotLeaf deriving (Show, Read)
Dropping the Int from the second constructor works (ignore the
constructor names, they are just place-holders).
��� [tommd@Mavlo Test]$ ./jtree
��� Give me a tree:
��� Leaf 43
��� Leaf 43
��� [tommd@Mavlo Test]$ ./jtree
��� Give me a tree:
��� NotLeaf
��� NotLeaf
--- OTHER TESTS ---
1) data TreeX = Leaf | NotLeaf 5 deriving (Show, Read)
Another unfortunate bug is that reversing the constructors (having
Leaf as a nullary constructor and NotLeaf taking an Int) causes
compilation to fail (using jhc-0.7.2-0).
2) data TreeX = Leaf Int | NotLeaf Int | OoopsLeaf deriving (Show, Read)
Works fine - notice it ends with a nullary constructor...
Hypothesis 1: All working Read derivations have data declarations with
a nullary constructor at the end.
3) data TreeX = Leaf Int | NotLeaf | OoopsLeaf Int deriving (Show, Read)
Fails in with 'case fell off', so H1 seems good
4) data TreeX = Leaf Int | NotLeaf | OoopsLeaf deriving (Show, Read)
Works.
5) data TreeX = Leaf | NotLeaf | OoopsLeaf Int deriving (Show, Read)
Fails to compile. Hypothesis 2: All working Read derivations that
don't cause compile issues have data declarations with non-nullary
first constructors.
Cheers,
Thomas
Daniel Fischer
> Like paolino, I did a couple tests and found:
>
>
> So the read for that does not work... but surprisingly...
>
> > data TreeX = Leaf Int | NotLeaf deriving (Show, Read)
>
> Dropping the Int from the second constructor works (ignore the
> constructor names, they are just place-holders).
>
>
> --- OTHER TESTS ---
> 1) data TreeX = Leaf | NotLeaf 5 deriving (Show, Read)
> Another unfortunate bug is that reversing the constructors (having
> Leaf as a nullary constructor and NotLeaf taking an Int) causes
> compilation to fail (using jhc-0.7.2-0).
>
> 2) data TreeX = Leaf Int | NotLeaf Int | OoopsLeaf deriving (Show, Read)
>
> Works fine - notice it ends with a nullary constructor...
> Hypothesis 1: All working Read derivations have data declarations with
> a nullary constructor at the end.
Must be something like that, it also dies badly reading Either (but reading integers
works):
module Main where
a, n :: Either Int Char
a = Right 'a'
n = Left 4
sa = "Right 'a'"
sn = "Left 4"
main :: IO ()
main = do
putStrLn "Showing:"
print (sa == show a)
print (sn == show n)
putStrLn "Reading:"
print (read "123" :: Integer)
print (a == read sa)
print (n == read sn)
results in
$ ./veither
Showing:
True
True
Reading:
123
veither_code.c:3642: case fell off
$ jhc --version
jhc 0.7.2 (0.7.2-0)
compiled by ghc-6.10 on a i386 running linux
Gour
>>>>>> "John" == John Meacham <jo...@repetae.net> wrote:
Hi John,
John> Yup. This was a major goal. compiling for iPhones and embedded
John> arches is just as easy assuming you have a gcc toolchain set up.
John> (at least with the hacked iPhone SDK.. I have never tried it with
John> the official one)
Is there any info whether it works on maemo platform?
Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: F96FF5F6
----------------------------------------------------------------
Braden Shepherdson
still works. I don't remember doing any magic, just using the Maemo
cross-compiler to build the output of jhc.
The only annoying part was having to build with jhc outside the
scratchbox environment and then build the C output inside the
scratchbox. This is necessary because jhc is not self-hosting and I
couldn't get GHC to build for Maemo.
The attempts to build GHC (back in the 6.8.2 days -- supposed
cross-platform bootstrapping works again in 6.12, maybe it'll work now)
and the success with JHC are documented at [1]. Actually, I just looked
and Dustin Weese succeeded where I had failed, and got an unregisterized
6.8 to bootstrap to Maemo.
I've since learned ARM(v4) assembly for an embedded systems course, I
might look into writing a properly registerized ARM back-end for GHC
6.12, now that the back-end overhaul is complete. That's definitely a
Copious Free Time project, since I don't intend to be doing any ARM dev
in Haskell or otherwise.
Braden Shepherdson
shepheb
[1] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc
Gour wrote:
> On Wed, 11 Nov 2009 00:37:59 -0800
>>>>>>> "John" == John Meacham <jo...@repetae.net> wrote:
>
> Hi John,
>
> John> Yup. This was a major goal. compiling for iPhones and embedded
> John> arches is just as easy assuming you have a gcc toolchain set up.
> John> (at least with the hacked iPhone SDK.. I have never tried it with
> John> the official one)
>
> Is there any info whether it works on maemo platform?
>
>
> Sincerely,
> Gour
>
>
>
> ------------------------------------------------------------------------
Gour
>>>>>> "Braden" == Braden Shepherdson <Braden.Sh...@gmail.com>
>>>>>> wrote:
Braden> This worked for me, though that was quite a while ago.
Braden> Presumably it still works. I don't remember doing any magic,
Braden> just using the Maemo cross-compiler to build the output of jhc.
Thank you for the info.
Braden> I've since learned ARM(v4) assembly for an embedded systems
Braden> course, I might look into writing a properly registerized ARM
Braden> back-end for GHC 6.12, now that the back-end overhaul is
Braden> complete.
It's no rush here, so having it in 6.12 would be cool.
Braden> That's definitely a Copious Free Time project, since
Braden> I don't intend to be doing any ARM dev in Haskell or otherwise.
Well, I'm thinking about having 'light' version of desktop app running
on something like N900, but it would involve gtk2hs as well,
but that's another part of the story...
John Meacham
> FWIW, I just compiled JHC 0.7.2 with ghc 6.12 , doing a couple of
> corrections to make it compile, which I don't think they are related to this
> *bug*. Testing the given code, it aborts for every inputs I give it "L 1",
> " T AND [L 1,L 2]" included.
> I couldn't make it compile using function "reads" instead.
I have not tested jhc with 6.12, it should compile with 6.8 and 6.10
seamlessly though, if you have found a way to get it to work with 6.12
and could post patches to the jhc list, that would be great though!
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
John Meacham
> Ops, the paste is wrong, but the bug is real. I mean, if I try to run
> the program with the right input, the program aborts in the same place,
> with the same error message:
>
> philip@desktop:~/jhctut$ ./jtestarbo
>
> Give me a tree:
>
> T AND [L 1, L 2]
>
> jtestarbo_code.c:2670: case fell off
Hmm... yes, a 'case fell off' error is always a bug in jhc one way or
another. I will have to investigate your program and find out why that
is happening. compiling with -fdebug can help find such errors, but
clearly there is something wrong.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
John Meacham
> John> Yup. This was a major goal. compiling for iPhones and embedded
> John> arches is just as easy assuming you have a gcc toolchain set up.
> John> (at least with the hacked iPhone SDK.. I have never tried it with
> John> the official one)
>
> Is there any info whether it works on maemo platform?
Indeed, in fact it has worked for the maemo platform in the past I know
because I tested with it once. I have not tested it in a long time, but
now there is a cross compilation framework so it should be easier. there
is a section in the manual on cross-compilation on how to set up new
target platforms, basically all it involves is pointing jhc at the right
gcc toolchain.
John Meacham
> The only annoying part was having to build with jhc outside the
> scratchbox environment and then build the C output inside the
> scratchbox. This is necessary because jhc is not self-hosting and I
> couldn't get GHC to build for Maemo.
Would you really want to have to run jhc _on_ your nokia 770 (or
whatever) just to compile Haskell programs for it? The need for
self-hosting in other compilers has always seemed like a deficiency in
their design, a compiler is just a pure function from source code to
output for a specified architecture. Said function is pure, it should
not depend on what platform the compiler happens to be running on any
more than any other pure function.
Not that having jhc run on the nokia would be a bad thing, but it should
not be required or provide any particular advantage for compiling
programs for the nokia. jhc running on your N800 should be able to
compile windows programs just as easily as jhc running on a windows
machine itself or a linux box or a mac box.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
John Meacham
> Do you use jhc when you develop jhc? I.e., does it compile itself.
> For me, this is the litmus test of when a compiler has become usable.
> I mean, if even the developers of a compiler don't use it themselves,
> why should anyone else? :)
Well, this touches on another issue, and that is that jhc is a native
cross-compiler. It never behaves differently if compiled by another
haskell compiler or is compiled on an alternate platform. There is never
a need to 'bootstrap' it, once you have jhc running anywhere then it is
as good as it would be if it is running everywhere. So to me,
self-hosting has never been a big issue as it doesn't provide any direct
"material" benefit. My time is better spent implementing more extensions
or improving the back end.
Of course, if jhc were to have a back-end that ghc didn't support that
was a useful platform for jhc to run on, then it would be a different
story. There would be a direct material benefit to having jhc being
self-hosting so it would become a priority.
Neil Mitchell
>> Do you use jhc when you develop jhc? �I.e., does it compile itself.
>> For me, this is the litmus test of when a compiler has become usable.
>> I mean, if even the developers of a compiler don't use it themselves,
>> why should anyone else? :)
>
> Well, this touches on another issue, and that is that jhc is a native
> cross-compiler. It never behaves differently if compiled by another
> haskell compiler or is compiled on an alternate platform. There is never
> a need to 'bootstrap' it, once you have jhc running anywhere then it is
> as good as it would be if it is running everywhere. So to me,
> self-hosting has never been a big issue as it doesn't provide any direct
> "material" benefit. My time is better spent implementing more extensions
> or improving the back end.
I think you might have missed Lennart's point. It's fair to say you do
a lot of Haskell development work while writing a Haskell compiler. If
you aren't using your compiler for your development work (in
particular for your compiler) then anyone trying to use it is likely
to bump in to problems. It's not that there are technical advantages
of self-compilation, but it is a good statement of faith from the
compiler author.
Anyway, I think the Haskell community needs more compilers, so I wish
you lots of luck with JHC!
Thanks, Neil
Lennart Augustsson
That was indeed my point. Since a compiler is a substantial program I
would have more confidence it a compiler that is self-hosting.
Surely you must have tried?
-- Lennart
Philippos Apolinarius
--- On Fri, 11/13/09, John Meacham <jo...@repetae.net> wrote:
From: John Meacham <jo...@repetae.net>
Subject: Re: [Haskell-cafe] Problem with JHC
To: haskel...@haskell.org
John
__________________________________________________________________
John Meacham
Hi, I believe this bug has been fixed in the darcs version, at least, it
is in my testing. The fix will be in 0.7.3, or you can try the version
from the darcs repository directly. Thanks for the bug report!
John
> --
John Meacham
> That was indeed my point. Since a compiler is a substantial program I
> would have more confidence it a compiler that is self-hosting.
> Surely you must have tried?
No, there are extensions that I use in jhc's code base that jhc itself
does not support yet (fundeps for instance). Although said extensions
would be nice and are on the list of things to add to jhc, there are
other tasks that are more important. I write a lot of code in Haskell,
so getting jhc to compile in jhc isn't much more important than getting
any of the other projects I work on to compile in it and I prioritize
accordingly. I am all about variety in the tools I use. I never
understood the desire to have it be self-hosting, I mean, sure it is a
nice abstract goal, but there are things with concrete benefits that are
more important to jhc right now. (of course, priorities change over
time.)
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Braden Shepherdson
> On Thu, Nov 12, 2009 at 10:44:22PM -0500, Braden Shepherdson wrote:
>> The only annoying part was having to build with jhc outside the
>> scratchbox environment and then build the C output inside the
>> scratchbox. This is necessary because jhc is not self-hosting and I
>> couldn't get GHC to build for Maemo.
>
> Would you really want to have to run jhc _on_ your nokia 770 (or
> whatever) just to compile Haskell programs for it? The need for
> self-hosting in other compilers has always seemed like a deficiency in
> their design, a compiler is just a pure function from source code to
> output for a specified architecture. Said function is pure, it should
> not depend on what platform the compiler happens to be running on any
> more than any other pure function.
>
> Not that having jhc run on the nokia would be a bad thing, but it should
> not be required or provide any particular advantage for compiling
> programs for the nokia. jhc running on your N800 should be able to
> compile windows programs just as easily as jhc running on a windows
> machine itself or a linux box or a mac box.
>
> John
>
It's not so much wanting to run it on the device (though that would be
fun just for the hack value). I was just saying that it adds an annoying
step to building using JHC, since you have to run JHC on the host, and
then gcc inside the scratchbox. It's not a limitation, just makes it
hard to write a working Makefile.
I was just playing around with it, so that never mattered much. I
suppose one could have two Makefiles in a proper project.
Braden Shepherdson
shepheb
Gour
>>>>>> "John" == John Meacham <jo...@repetae.net> wrote:
John> Would you really want to have to run jhc _on_ your nokia 770 (or
John> whatever) just to compile Haskell programs for it?
No. I'd be satisfied with the ability to develop in Haskell for
Maemo/Moblin and run apps on those platforms.
Henning Thielemann
On Fri, 13 Nov 2009, John Meacham wrote:
> On Fri, Nov 13, 2009 at 08:55:51PM +0000, Lennart Augustsson wrote:
>> That was indeed my point. Since a compiler is a substantial program I
>> would have more confidence it a compiler that is self-hosting.
>> Surely you must have tried?
>
> No, there are extensions that I use in jhc's code base that jhc itself
> does not support yet (fundeps for instance).
Maybe you can skip fundeps and move to Type families immediately.
> Although said extensions would be nice and are on the list of things to
> add to jhc, there are other tasks that are more important. I write a lot
> of code in Haskell, so getting jhc to compile in jhc isn't much more
> important than getting any of the other projects I work on to compile in
> it and I prioritize accordingly. I am all about variety in the tools I
> use. I never understood the desire to have it be self-hosting, I mean,
> sure it is a nice abstract goal, but there are things with concrete
> benefits that are more important to jhc right now. (of course,
> priorities change over time.)
A JHC compiled JHC might be faster and noticeably smaller? My current jhc
executable is 15 MB.
Bayley, Alistair
> [mailto:haskell-ca...@haskell.org] On Behalf Of John Meacham
>
> On Fri, Nov 13, 2009 at 08:55:51PM +0000, Lennart Augustsson wrote:
> > That was indeed my point. Since a compiler is a
> substantial program I
> > would have more confidence it a compiler that is self-hosting.
> > Surely you must have tried?
>
I think you did, once. Quoting from here (from section "The story of
jhc"):
http://repetae.net/computer/jhc/jhc.shtml
"Writing a compiler is also doubly efficient to begin with, since if you
self-compile improvements not only give you a better optimizer, but also
speed up your self-compiled compiler."
I was looking forward to the day jhc became self-hosting.
Alistair
*****************************************************************
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*****************************************************************