[Haskell-cafe] Haskell/JS -- better through typeclasses?

[John A. De Goes]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe