I created a GHC patch that spits out the generated Template Haskell code to
a file with -dump-to-file -ddump-splices
https://ghc.haskell.org/trac/ghc/ticket/9126
On Sat, Jul 5, 2014 at 8:18 PM, adam vogt vogt.a...@gmail.com wrote:
Zeroth takes the first approach. It only supports a subset of
] to GHCJS to make it run Template Haskell
code on node.js, rather than using the GHC linker. GHCJS has supported TH
for a long time now, but so far always relied on native (host) code for
it.
This is the main reason that GHCJS always builds native and JavaScript
code
for everything (another
mechanical subtasks)
On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman stege...@gmail.com
wrote:
hi all,
I've added some code [1] [2] to GHCJS to make it run Template Haskell
code on node.js, rather than using the GHC linker. GHCJS has
supported TH
for a long time now, but so far
On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald carter.schonw...@gmail.com
wrote:
does JHC support template haskell?
Pretty sure TH is too closely tied to ghc.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com
Actually, I was looking into it a little, and template haskell could
effectively be implemented by a pre-processor and a portable library
that is compiler independent. If one could get ghc to spit out the
template haskell source after it expands it then that can be fed to
jhc as a quick first
The target compiler would have the TH libraries, which could be made
to be portable. The external program would just extract the TH bits
and turn them into a program that spits the TH expanded output to a
new file to compile, and repeat the process til no TH expansions exist
and finally that is
/template-haskell-2.9.0.0/docs/Language-Haskell-TH-Syntax.html
, the Quasi class for the required functionality). This would mean
serializing all names with types modules, annotations, instances. I briefly
looked into this for GHCJS but decided that just querying the compiler
would be better.
On Sat
Zeroth takes the first approach. It only supports a subset of TH
(DecsQ splices) however.
http://hackage.haskell.org/package/zeroth
https://github.com/aavogt/zeroth is a fork that works with more recent
haskell-src-exts and ghc
On Sat, Jul 5, 2014 at 3:59 PM, John Meacham j...@repetae.net
and making
maintaining it harder, then I’m open to your proposals.
I think most of the communication code could go into a separate executable
that can be built by the user for the target-specific communication. The
GHC API facing part of the implementation in GHCJS is under 300 lines
on concrete mechanical subtasks)
On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman stege...@gmail.com
wrote:
hi all,
I've added some code [1] [2] to GHCJS to make it run Template Haskell
code on node.js, rather than using the GHC linker. GHCJS has supported TH
for a long time now, but so far
Yes! This would definitely be of great interest to users of the
Android cross compilers. It should be quite feasible to drive a TH
runner process on a development device or emulator. Having genuine TH
support would be a huge improvement to the usefulness of GHC in a
cross compiling scenario.
I
I think GHC could use more or less the same communication method as GHCJS
now does: Start some user-specifiied process and send messages through
pipes (GHCJS uses stdin/stderr of the node process), with the difference
that it would get dynamic libraries for the target rather than blobs of JS
code
] [2] to GHCJS to make it run Template Haskell
code on node.js, rather than using the GHC linker. GHCJS has supported TH
for a long time now, but so far always relied on native (host) code for it.
This is the main reason that GHCJS always builds native and JavaScript code
for everything (another
tooling into 7.10, i'm all
for it :) (and willing to help on concrete mechanical subtasks)
On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman stege...@gmail.com
wrote:
hi all,
I've added some code [1] [2] to GHCJS to make it run Template Haskell
code on node.js, rather than using the GHC linker
hi all,
I've added some code [1] [2] to GHCJS to make it run Template Haskell code
on node.js, rather than using the GHC linker. GHCJS has supported TH for a
long time now, but so far always relied on native (host) code for it. This
is the main reason that GHCJS always builds native
wow, this is great work!
If theres a clear path to getting the generic tooling into 7.10, i'm all
for it :) (and willing to help on concrete mechanical subtasks)
On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman stege...@gmail.com wrote:
hi all,
I've added some code [1] [2] to GHCJS to make
the generic tooling into 7.10, i'm all
for it :) (and willing to help on concrete mechanical subtasks)
On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman stege...@gmail.com
wrote:
hi all,
I've added some code [1] [2] to GHCJS to make it run Template Haskell
code on node.js, rather than using
hi all,
I've been working on GHCJS [1] for a while and am trying to get it to
work on 64 bit GHC.
A quick background: GHCJS uses the GHC API to generate STG, which it
then translates to JavaScript. It uses slightly patched versions of
the integer-gmp, base and ghc-prim libraries and supports
On 27/06/2012 13:24, Nathan Hüsken wrote:
I hope this is the correct list to ask this question.
I am trying to compile the ghcjs compiler. I am on ubuntu 12.04 and have
ghc-7.4.1 installed (via apt-get).
I am following the instruction I found here: https://github.com/ghcjs/ghcjs
The first
Hi,
I hope this is the correct list to ask this question.
I am trying to compile the ghcjs compiler. I am on ubuntu 12.04 and have
ghc-7.4.1 installed (via apt-get).
I am following the instruction I found here: https://github.com/ghcjs/ghcjs
The first trouble comes with git pull ghcjs. I get
On 04/08/2011 21:02, Simon Peyton-Jones wrote:
| data LiteralDesugaring m =
|LiteralDesugaring
| { desugarInt :: MonadThings m = Integer - m CoreExpr
| , desugarWord :: MonadThings m = Integer - m CoreExpr
...
I am not sure why you want to control the desugaring of literals.
to predict exactly what's needed. Again, I suggest you try doing
this and send us a patch.
I think I should do it. From GHCJS perspective I need to abstract out
literal desugaring and foreign exports/imports desugaring. Desugarer
uses these functions from MkCore module now:
mkIntExpr :: Integer
| data LiteralDesugaring m =
|LiteralDesugaring
| { desugarInt :: MonadThings m = Integer - m CoreExpr
| , desugarWord :: MonadThings m = Integer - m CoreExpr
...
I am not sure why you want to control the desugaring of literals. Why
literals? And why is literals enough?
| But
| So then parseDynamicFlags should be split into two layers, the lower
| layer returning unused flags, and the upper layer generating errors.
|
| It's not that simple. In
| ghcjs -O -someflag something -Wall
| is something an argument to someflag, or a file to be compiled?
It think
On Fri, Aug 5, 2011 at 12:02 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
| data LiteralDesugaring m =
| LiteralDesugaring
| { desugarInt :: MonadThings m = Integer - m CoreExpr
| , desugarWord :: MonadThings m = Integer - m CoreExpr
...
I am not sure why you want to
that [CoreBind] into JavaScript
| == Command line interface ==
| This works, but I'm not allowed to parse some custom flags used by
| GHCJS code and not by GHC API.
| ParseDynamicFlags throws UsageError if it encounters some unknown flags.
So perhaps that's the problem. parseDynamicFlags could
interface ==
| This works, but I'm not allowed to parse some custom flags used by
| GHCJS code and not by GHC API.
| ParseDynamicFlags throws UsageError if it encounters some unknown flags.
So perhaps that's the problem. parseDynamicFlags could perfectly well simply
return any un-recognised flags
as used with C-call.
* cross-compilation. GHCJS doesn't work properly on 64bit systems.
Javascript lacks real integers and we need to emulate them with
Javascript bit-operations. But all javascript bit-operations work with
32 bits. To make Javascript code readable and fast we need to make
Haskell
On 03/08/2011 11:09, Victor Nazarov wrote:
On Wed, Aug 3, 2011 at 11:30 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
So perhaps that's the problem. parseDynamicFlags could perfectly well simply
return any un-recognised flags. Indeed, I thought it did just that -- it
certainly
arguments if they are something
like filenames, but it throws error if un-consumed argument starts
with dash.
Maybe you can wrap the GHCJS into a plugin now that plugin support is finally
in GHC 7.2.* , and generate the javascript as a side-effect [1]?
Then you can pass option specifically to GHCJS
On Wed, Aug 3, 2011 at 11:55, Christiaan Baaij
christiaan.ba...@gmail.comwrote:
So perhaps that's the problem. parseDynamicFlags could perfectly well
simply return any un-recognised flags. Indeed, I thought it did just that --
it certainly returns a list of un-consumed arguments. If it
then parseDynamicFlags should be split into two layers, the lower
layer returning unused flags, and the upper layer generating errors.
It's not that simple. In
ghcjs -O -someflag something -Wall
is something an argument to someflag, or a file to be compiled?
I think the best approach is to make
Hello,
I'm a maintainer and creator of GHCJS tool [1].
GHCJS currently uses GHC API to produce Javascript code from Haskell sources.
There is a great interest to the project, but there have been little
progress recently.
I'm considering the future of it and I'd like to get some advices
and return the rest GHC's flags untouched.
Your best bet is to use '--' or something similar to demarcate GHCJS
flags, and GHC flags, and then manually split them up before passing
them off to your preferred command line parser.
Though this vaguely sounds like something that might be nice
, but I would like to support
exports and static/dynamic wrappers. GHC generates C-code to support
them, and GHCJS should generate Javascript-code,
but I have no idea how to use GHC API to generate custom (Javascript)
stubs. Is it possible at all?
That is certainly not; you'll need to patch
on javascript keyword.
For now I'm using (abusing) ccall calling convention and simple
imports works pretty well, but I would like to support
exports and static/dynamic wrappers. GHC generates C-code to support
them, and GHCJS should generate Javascript-code,
but I have no idea how to use GHC API
On Wed, Aug 3, 2011 at 00:31, John Lask jvl...@hotmail.com wrote:
What is really required is a pluggable back-end infrastructure - whereby
various back-ends could be maintained (or not) at the discretion of their
originators and separate to the official ghc back-ends.
I guess I'm confused; I
On 3/08/2011 2:10 PM, Brandon Allbery wrote:
On Wed, Aug 3, 2011 at 00:31, John Laskjvl...@hotmail.com wrote:
What is really required is a pluggable back-end infrastructure - whereby
various back-ends could be maintained (or not) at the discretion of their
originators and separate to the
38 matches
Mail list logo
