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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
