On Wed, Oct 27, 2010 at 7:46 PM, Martijn Schrage <[email protected]> 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
