[Haskell-cafe] Haskell/JS -- better through typeclasses?
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
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
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
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/26 John A. De Goes j...@n-brain.net: 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. This was what I was originally writing in about, yeah. However, thinking it over I realize there are some serious problems. We really do want to work with a restricted subset of Haskell that is more amenable to translation -- one with finite arrays and most every type translatable to JSON. I'm not particularly concerned with non-strict evaluation, either. Strict is preferable wherever it would not alter the outcome. I fear that requires us to know, statically, whether potentially infinite structures like lists are finite or infinite. I'm not sure about this but I suspect that's a major stumbling block. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
On Apr 26, 2009, at 10:18 AM, Jason Dusek wrote: This was what I was originally writing in about, yeah. However, thinking it over I realize there are some serious problems. We really do want to work with a restricted subset of Haskell that is more amenable to translation -- one with finite arrays and most every type translatable to JSON. For purposes of cross-platform development, it's important the subset be minimally restricted (at least in my case). I fear that requires us to know, statically, whether potentially infinite structures like lists are finite or infinite. I'm not sure about this but I suspect that's a major stumbling block. I think it's easy to determine if something is definitely finite (certainly any list passed into an exported Haskell function must be finite, since JS doesn't have infinite lists). Determining if something is definitely infinite is not as easy, but it might be sufficient to use lazy evaluation whenever there is a possibility that a structure might be infinite. Any function exported to JavaScript must return a finite list. Annotations would be another way of handling this. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell/JS -- better through typeclasses?
John wrote: 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). What I presented is of course not a complete solution; this is just a tool to construct Javascript expressions in haskellized type-safe form. What I also mentioned: this monadic form may be an end-point for some other conversion, like GRIN. This answers the question how to translate a true Haskell program (like a parser) into Javascript (or a similar language). There are some experimental compilers with GRIN backends, plus I did my own experiments with GRIN that gave me some ideas. So I would just look at it as a starting point of some new family of tools which hopefully will end up opening possibility to translate Haskell things to Javascript. PS For now I am more concerned with the IDL part of it, but any suggestions on GRIN are welcome. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/26 John A. De Goes j...@n-brain.net: 2009/04/26 Jason Dusek: This was what I was originally writing in about, yeah. However, thinking it over I realize there are some serious problems. We really do want to work with a restricted subset of Haskell that is more amenable to translation -- one with finite arrays and most every type translatable to JSON. For purposes of cross-platform development, it's important the subset be minimally restricted (at least in my case). Cross-platform in what sense? Like browser/GTK/QT? I fear that requires us to know, statically, whether potentially infinite structures like lists are finite or infinite. I'm not sure about this but I suspect that's a major stumbling block. I think it's easy to determine if something is definitely finite (certainly any list passed into an exported Haskell function must be finite, since JS doesn't have infinite lists). That's fair; but internal lists may not be. Determining if something is definitely infinite is not as easy, but it might be sufficient to use lazy evaluation whenever there is a possibility that a structure might be infinite. Any function exported to JavaScript must return a finite list. That is, I think, a most reasonable restriction. Annotations would be another way of handling this. Why would annotations be preferable to a restricted set of types that implement, say,`Foldable` or `Traversible`? I think finite collections would be of use for other environments where we can't expect a working RTS. In fact I would not be surprised if that this sort of thing is not what's been done for GPUs by other Haskellers. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/26 Dimitry Golubovsky golubov...@gmail.com: John wrote: 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). What I presented is of course not a complete solution; this is just a tool to construct Javascript expressions in haskellized type-safe form. What I also mentioned: this monadic form may be an end-point for some other conversion, like GRIN. This answers the question how to translate a true Haskell program (like a parser) into Javascript (or a similar language). There are some experimental compilers with GRIN backends, plus I did my own experiments with GRIN that gave me some ideas. So I would just look at it as a starting point of some new family of tools which hopefully will end up opening possibility to translate Haskell things to Javascript. PS For now I am more concerned with the IDL part of it, but any suggestions on GRIN are welcome. I didn't mean to ignore your earlier mail -- I felt John's was easier to comment on. As some people remarked in the other thread, it's maybe not so unreasonable that the best way to start with translating Haskell to JavaScript is developing a DSL for writing JavaScript in Haskell. When I said that earlier work on Haskell/JS was not directly relevant to my interests, it was not my intention to suggest it was all silly stuff. I'm really just trying to get some perspective on how to go about this sort of thing; it's desirable to me to be able stuff Haskell libs into environments that only allow JavaScript or Python. I'm beginning to appreciate that the core translation I imagined is perhaps not the most direct route. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell/JS -- better through typeclasses?
I'd like to be able to translate Haskell to JavaScript. Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in Haskell and then reuse it on the client side. No need to handle all the DOM events or implement multi-threading. Of course, the place to start is by reading the commentary. A little bit of browsing suggests some questions of strategy: . Maybe a new backend is not the right thing? All the backends seem to be for real computers with real instruction sets. . Is it better to just work on transforming Core into JS directly? It seems that External Core is still in limbo. . Some translations strike me as baffling in principle. For example, a value like `ones`: ones = 1 : ones We'd want to avoid most native JavaScript containers, it seems; however, we are then unable to leverage the speed of native containers. It's entirely possible that translating Haskell to JavaScript may turn out not to be the best idea; maybe it is better to have a type class for types (for example, `Parser Char`) to provide their own translators? The it would be straightforward to prevent translation of programs that use concurrency libs, native ops or `IO`. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
On 25 Apr 2009, at 21:53, Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
I tried using the jhc javascript compiler back end a year or so ago. It was too rough to use in production, but it did output javascript from haskell. thomas. 2009/4/25 Miguel Mitrofanov miguelim...@yandex.ru: On 25 Apr 2009, at 21:53, Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. ___ 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
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
On second thought, it was yhc, not jhc: http://lambda-the-ultimate.org/node/1836 2009/4/25 Thomas Hartman tphya...@gmail.com: I tried using the jhc javascript compiler back end a year or so ago. It was too rough to use in production, but it did output javascript from haskell. thomas. 2009/4/25 Miguel Mitrofanov miguelim...@yandex.ru: On 25 Apr 2009, at 21:53, Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. ___ 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
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
On Apr 25, 2009, at 13:53 , Jason Dusek wrote: I'd like to be able to translate Haskell to JavaScript. http://haskell.org/haskellwiki/Yhc/Javascript ? Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in That's not exactly limited; building a self-contained program is easier than producing something that seamlessly adapts between different runtimes with very different notions of how the world works. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/25 Brandon S. Allbery KF8NH allb...@ece.cmu.edu: 2009/04/25 Jason Dusek: I'd like to be able to translate Haskell to JavaScript. http://haskell.org/haskellwiki/Yhc/Javascript ? Dead. Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in That's not exactly limited; building a self-contained program is easier than producing something that seamlessly adapts between different runtimes with very different notions of how the world works. What I mean is a bucket of JavaScript functions. It would be fine to hide all the data constructors and type definitions. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/25 Miguel Mitrofanov miguelim...@yandex.ru: 2009/04/25 Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. Many persons use images in the form of analogy or metaphor to communicate a message. However, my goals are more limited -- I'd like to use images without analogy or metaphor. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/25 Thomas Hartman tphya...@gmail.com: 2009/04/25 Thomas Hartman tphya...@gmail.com: I tried using the jhc javascript compiler back end a year or so ago. On second thought, it was yhc, not jhc: http://lambda-the-ultimate.org/node/1836 Yeah, I think that thing has been dead for awhile. Also it does a lot more than I want -- I don't want to write my UI logic in Haskell at present. The AJAX toolkits are pretty good and it would be a waste to try to translate them into Haskell and keep them updated. I would like to be able to write a lot of supporting code in Haskell, though -- like parsers. Actually, parsers are really all I care about at present. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
I'd like this functionality, as well, but it doesn't exist, at least for Haskell. If you don't need a 100% pure functional language, and don't need the bells and whistles of the Haskell type system, you might be interested in SML -- a purer relative of the more widely-known Ocaml. There's a tool for converting SML to JavaScript: http://www.itu.dk/people/mael/smltojs/ It allows you to export SML functions so they can be called by JavaScript. Moreover, it has a reactive library built in, does pretty decent optimization, lets you manipulate the DOM, and is up to version 4.3.5. Haskell doesn't have anything close! Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 25, 2009, at 11:53 AM, Jason Dusek wrote: I'd like to be able to translate Haskell to JavaScript. Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in Haskell and then reuse it on the client side. No need to handle all the DOM events or implement multi-threading. Of course, the place to start is by reading the commentary. A little bit of browsing suggests some questions of strategy: . Maybe a new backend is not the right thing? All the backends seem to be for real computers with real instruction sets. . Is it better to just work on transforming Core into JS directly? It seems that External Core is still in limbo. . Some translations strike me as baffling in principle. For example, a value like `ones`: ones = 1 : ones We'd want to avoid most native JavaScript containers, it seems; however, we are then unable to leverage the speed of native containers. It's entirely possible that translating Haskell to JavaScript may turn out not to be the best idea; maybe it is better to have a type class for types (for example, `Parser Char`) to provide their own translators? The it would be straightforward to prevent translation of programs that use concurrency libs, native ops or `IO`. -- Jason Dusek ___ 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
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
For parsers, there is also a LALR(1) generator - http://jscc.jmksf.com/ - though I have not had personal experience with it. --A ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
Interesting, thank you. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
