Hi,
Not useless at all, to compile Yhc with Hugs takes 5 seconds on a
Pentium 750, to compile it with GHC takes forever... The reason I know
this is because I have been developing Yhc under WinHugs for sometime
- usually just checking it type checks, and then compiling with GHC
later. Its a lot faster than using GHC. Certainly for things like the
command line flag parser I developed them entirely in Hugs.
In fact, Hugs is the whole reason why Yhc has no cpp in its entire
code base - its the first thing I eliminated from nhc98's codebase.
It is however important to remember that Hugs isn't as pure C as might
be hoped for - it does some pretty horrific things to the
architectures call stack - but having the ability to use Yhc with Hugs
is certainly very important to me :)
And finally, Yhc is not dependant on C at any level - we can depend on
.NET, JVM or Python instead of C - JVM certainly has a hardware
implementation, and the other languages may be able to get to the
machine level without C :)
Thanks
Neil
On 7/9/06, Isaac
Warning: Potentially useless (but then again potentially interesting or useful) musing ahead
It occured to me that if we're going to be compilable with GHC and Yhc, we might as well eventually make sure to work with other Haskell implementations as well, like hugs. Of course running Yhc under hugs normally would be a bit stupid because of the speed. And I realized that, since portable Yhc bytecode of Yhc can be distributed, self-compiling Yhc using hugs would not be necessary for bootstrapping from no initial haskell implementation (Hugs is written in C, not haskell as most haskell implementations are) (either way requires that the Yhc-bytecode interpreter be compilable; I'm assuming it's in C). However there are some interesting properties of such a thing: * Every additional compiler Yhc works with helps ensures the code's portability/standardness. * It works for someone who really wants to compile things only from their original sources. Likewise, it helps to cure the property of a program only being defined in terms of itself (and fixability if it's buggy). All known Haskell implementations directly depend at some point on a C implementation, which is probably written in C, so there's no getting around that (although C-- looks interesting; GHC still has a substantial RTS(run-time system) written in C I believe, but jhc deliberately doesn't). Of course this is irrelevant in practice, as gcc and ghc are both heavily tested and have versions that work quite well enough. * Understandability, related to how much it is defined in terms of itself (to someone who knows C and good programming but can't understand natural-language explanations for some mysterious reason).I presume that C-running-Haskell is still a higher level than C-running-Yhc-bytecode, and thus more comprehensible. Now, as to the "mysterious reason": maybe this "someone" is a powerful computer analysing (parts of) a computer system. Perhaps for bugs or properties of it. Perhaps it's some Martians, some space-aliens, some automated code audits, whatever. To me, all this stuff (in part deliberately) sounds like science fiction that could come true in some years. Actually, it could be a paranoid human looking through all code for actions it takes that are undesired (rather than (or in addition to!) using the system's security measures well).
Any thoughts? (Any mistaken assumptions?) Basically the summary is: practically useless, but cool.
Isaac _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org//mailman/listinfo/yhc