Monday, December 26, 2005

Crazy Ideas

Having a small, clean, simple, production strength Haskell compiler lets a lot of people come up with Crazy ideas that just weren't feasible before. (alright, so Yhc certainly isn't production strength yet, but it could be without too much work...)

Some of the crazy ideas are listed at on the wiki, some others have been sent out in emails. Quite a lot aren't crazy at all, but would be really useful! Just a quick summary of some side projects/tools that are being developed, or have been thought of:
  • Haskell HBC -> Java bytecode
  • Javascript runtime for HBC files
  • Python runtime for HBC files
  • Playstation port (entirely speculation so far)
I also came up with a new crazy idea for Yhc, HsNub. Have you ever written a function, and later found out that it did the same as a function in the prelude? Take the Yhc code base, I recently eliminated the function second, which is equivalent to the Prelude function const. It would have been nice if something spotted this and gave out a warning. With a portable bytecode, this isn't that much work - two functions can be seen as equivalent if they are identical at the bytecode level. I intend to write this tool once I have a working bytecode library - I don't expect it to take more than an hour at most - thats the nice thing about having a relatively simple Haskell implementation!


Blogger Lunch Menu said...

How about a translator to Flash ActionScript bytecode ?

12:51 AM  
Blogger Neil Mitchell said...

Certainly possible - I guess a bytecode convertor could be written for any bytecode which is turing complete, which I guess is pretty much all of them.

Want to volunteer? :)

11:44 AM  
Blogger Max said...

is it easy enough to write yhc bytecode to caml and vice versa translator?
as far as i know caml has a very good bytecode runtime and a lot of good libraries.
I'm not familiar enough with both formats but the whole idea seems ... such translator and consequently yhc <-> caml interoperability would be a bomb.

10:00 PM  
Blogger Neil Mitchell said...

The biggest difference between the runtimes is that Haskell is lazy and Caml is strict - that makes for a very different bytecode format - not to say it couldn't be done, but the interoperability with libraries etc. might be a bit limited.

A better approach would be a Haskell -> O'Caml convertor, which I know someone is working on. That would give perfect library useage between the two.

4:18 PM  
Blogger Tom Davie said...

HsNub sounds like a stunning idea, except that it would rely on remarkable consistency in the code generation... I guess you could make it better by allowing certain swaps in instruction order etc.

One thing I wonder is if you might end up picking out things like "this specific specialization of your function could be a specialization of a prelude function instead" or things of this like... Which would just be plain irritating.


3:28 PM  
Blogger John said...

Since Haskell is sometimes called
a strongly type Lisp, and Yhc has
mobile byte code, what do you think
about the idea of writing Treemacs
in Yhc. Treemacs would have a slightly different metaphor than
emacs. Basically it would be a
two pane application like Windows
Explorer with a tree in the left
pane. The selected node in the tree
would be rendered with its associated
editor in the right pane. You would
script this environment in Yhc and
it could chew on Yhc byte code libraries. Both the tree and editor panes could
have plug-ins written in yhc, the default plugins being a file system
browser for the tree pane and a text editor for its associated window pane. Normally the tree pane is
hidden and an emacs emulation mode
could be used. It may be interesting to write this instead
on top of a Mozilla frameworks embedding the Yhc interpreter into
this Treemacs application which could then be called either Treemacs
or perhaps a "business browser".
There is a lot more to this concept
than I'm describing here. Is this
crazy or doesn't it sound interesting?

5:25 PM  

Post a Comment

<< Home