[Haskell-cafe] [ANNAUNCE] ghcjs-0.1.0 Haskell to Javascript compiler

[Victor Nazarov]

On Wed, Oct 27, 2010 at 7:46 PM, Martijn Schrage <martijn at oblomov.com> wrote:
> On 27-10-10 16:20, Victor Nazarov wrote:
>>
>> Very cool. I'll incorporate your changes, If you don't mind.
>
> Not at all.
>>
>> However, I have some minor remarks.
>> You shouldn't override hscall function, or you may break partial
>> application implementation. And you shouldn't overide properties of
>> evalFn, I wonder that this doesn't break your example...
>
> Ah, yes, that was the guessing part. I just hacked around a bit and thought
> I'd leave the correct definition to someone who actually knows what they're
> doing :-)
>>
>> var evalFn = new $hs.Func(1);
>> evalFn.evaluate(arg) = function(arg) {
>>   var argStr = $hs.fromHaskellString(arg);
>>   var res = eval(argStr);
>>   return $hs.toHaskellString(arg); // This function should be added to
>> $hs object/namespace
>> }
>
> This works without any problems (after changing the second line to:
> "evalFn.evaluate = function(arg) {")
>>
>> I think we should do something like this:
>>
>> data JsObject = ... -- Should be made abstract
>>
>> and
>>
>> eval :: String ->  [JsObject] ->  JS JsObject
>>
>> So we can pass around javascript-objects in haskell program and bind
>> them back into javascript calls.
>> And use some conversion functions in case when we need data:
>>
>> jsObjectToString :: JsObject ->  JS String
>> jsObjectToInt :: JsObject ->  JS Int
>
> Yes, that seems logical. The JsObjects can then be treated similar to
> IORefs.
>
> What are your plans with the package? In my opinion, this work could be
> extremely useful for building Ajax apps, and it doesn't seem to be that far
> from being usable already.
>
> Some interesting near-future work I can think of:
>
> - Make it work on all major browsers
This shouldn't be a problem...

> - A faster and more robust module loader (now it loses a lot of time on 404
> errors, trying to access modules in the wrong package dir)
I agree that this is important. I'll look into it...

> - Basic type checking for the top-level Haskell functions
I think this should be implemented via FFI export implementation.

> - Marshaling between Haskell and JavaScript values
Again It's mostly implementation of Haskell FFI

> - JQuery support
> - Nice ways to build JavaScript (and JQuery) expressions in Haskell
Dmitry Golubovski had a code generator from WebIDL wich he used to
support HTML5 DOM in YHC.

> - Support more libraries and packages (Parsec would be interesting)
>
I think Parsec should work right now out of the box. But I don't have
time to investigate it...

> I can find some spare time to work on this. I'm sure there will be others as
> well.
>

I want to make code generator more smart and generate more optimized
code. To archive this I need to rewrite it in Monad or
ApplicativeFunctor style. I need Reader monad there to pass some
environment.

I think ghc-packages support is rather trivial to add. So module
loader will always know the one true location of module.

I want to implement continuation passing style calling convention for
Haskell-values as an alternative to two existing ones: plain and
trampoline. This will even allow multithreading emulation (with
setTimer as a scheduling mechanism...)

And last, I want to dig into FFI implementation. I think GHC doesn't
allow extensible FFI. So you won't be able to write "javascript"
calling convention in Haskell source file. But I think we can overcome
this using "ccall" for example...

I don't know what tasks are of most priority. I do what I feel like
doing :) I'll be very interested to see what other people can do with
all this. And I think that we should switch to application driven
development some time with something like Yampa-based game running in
web-browser...

-- 
Victor Nazarov