I can't speak for Jason, but for me, this is not very useful. I don't want to write in a Haskell DSL, I want to write in Haskell. And not the whole program, either, just the parts that really lend themselves to functional programming (parsers, numeric computations, code generators, various algorithms). Which means I need to be able to call Haskell functions from JavaScript. I'm not particularly concerned with non-strict evaluation, either. Strict is preferable wherever it would not alter the outcome. There is no good Haskell solution for this (though your own work in this area is clearly the best available). What I'd really like is something like SMLtoJS (possibly without the reactive library), but for Haskell. And that does not exist. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Apr 26, 2009, at 7:44 AM, Dimitry Golubovsky wrote:
Jason and everybody interested,
Please check out a package I recently (just by coincidence: I haven't seen this topic on the list until after I uploaded it) uploaded to Hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/jsmw-0.1
This is a basic monadic interface to Javascript code generator (based on WebBits), providing sort of a macro (like in macro-assembler) facility. HJScript was used as a (sort of) prototype, but I chose slightly different notation for EDSL.
From here, I think two directions may be taken:
1. Some techniques are described in the GRIN thesis [1] how to convert a Haskell core to monadic form. These may be explored for this case.
2. Similarly to how the Web Consortium defined interfaces to its components using IDL *, Haskell modules converted to Javascript may expose their interfaces same way, thus providing a basis for a reusable component-based approach.
Any discussions and suggestions are welcome.
From my own impressions, EDSL approach is better for interactive/AJAX parts of a Javascript application, as translation of non-strict evaluation (like it was done in the Yhc/Javascript project) just causes a lot of code generated, and does not improve the user interaction performance at all. For other (internal) components, translation from Haskell may be more appropriate, just to be able to reuse the existing libraries.
One of experiments with Yhc involved a user-exposed form, and a parser to validate user's input. With this hybrid approach, the user interface part might be coded using an EDSL, and the parser could be translated from Haskell core. An IDL might be generated for the parser interface, thus making the parser module a reusable component. These are of course just thoughts and ideas for now.
------------------------------------ * See the DOM package: this is an auto-generated Haskel approximation of IDL specs provided for the basic DOM components.
[1] http://www.cs.chalmers.se/~boquist/phd/index.html [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/DOM-2.0.1
-- Dimitry Golubovsky
Anywhere on the Web _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe