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 wrote:
> Zeroth takes the first approach. It only supports a subset of TH
> (DecsQ splices)
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 wrote:
> Actually, I w
rg/package/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
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 the
How would you do reification with that approach?
On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote:
> 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
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 pass,
On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald 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 ballb...@sinenomine.net
> >>>
> >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald
> >>> wrote:
> >>>> wow, this is great work!
> >>>>
> >>>> If theres a clear path to getting the generic tooling into 7.10, i'm
> all
> >>>
l
>>>> for it :) (and willing to help on concrete mechanical subtasks)
>>>>
>>>>
>>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman
>>>> wrote:
>>>>> hi all,
>>>>>
>>>>> I've adde
t;>
>>>> 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
omplicated 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
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
>>> w
ote:
>>
>> 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
>
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
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 wou
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
> wrote:
>
>> hi all,
>>
>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>>
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 wrote:
> hi all,
>
> I've added some code [1] [2] to GHCJS to m
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 nativ
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 sup
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&qu
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 literal
On Fri, Aug 5, 2011 at 12:02 AM, 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 d
| > 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 c
| 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?
| B
for a callback, like we do for printing error messages,
> so the GHC API client passes in a callback to do whatever backend-specific
> desugaring is required. The callback mechanism could be used for lots of
> things - I can imagine it growing into a record of backend-specific
> funct
gt; >like filenames, but it throws error if un-consumed argument starts
> >with dash.
>
> 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 s
On Wed, Aug 3, 2011 at 11:55, Christiaan Baaij
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 returns a list of un-consumed arguments. If it doesn't perhaps
> that's a
bug.
>
> parseDynamicFlags returns un-consumed 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 sid
On 03/08/2011 11:09, Victor Nazarov wrote:
On Wed, Aug 3, 2011 at 11:30 AM, Simon Peyton-Jones
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 returns a list of un-consume
tom ffi calling conventions and custom format for
call specification, Javascript or JVM will require radically different
call specification then simple function-name as used with C-call.
* cross-compilation. GHCJS doesn't work properly on 64bit systems.
Javascript lacks real integers and we need to
ugh GHC API.
- then convert StgBindings to 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.
>
> S
to convert 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. par
On 3/08/2011 2:10 PM, Brandon Allbery wrote:
On Wed, Aug 3, 2011 at 00:31, John Lask 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-end
On Wed, Aug 3, 2011 at 00:31, John Lask 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 thought the
parse error 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
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 to generate custom (Javascript)
> >
filter out some
> specified flags 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 vaguel
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
39 matches
Mail list logo
