[Yhc] hugs + Yhc, or similar...

[Neil Mitchell]

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 <isaacdupree at charter.net> wrote:
> 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 at haskell.org
> http://www.haskell.org//mailman/listinfo/yhc
>