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
I'm not sure I correctly understand your approach, but to have the template
haskell reification work without any runtime communication with the
compiler you'd have to include the entire typechecker state, at least for
all names reachable from the splice (see
http://hackage.haskell.org/package/templ
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
does JHC support template haskell?
On Sat, Jul 5, 2014 at 12:02 PM, Scott Turner <2hask...@pkturner.org> wrote:
> It installed and worked on my Nexus 5.
>
> On 2014-07-04 00:43, Dominick Samperi wrote:
> > Hello John,
> > I tried to install the Haskell demo Cube on my Nexus 7
> > and got: Error:
It installed and worked on my Nexus 5.
On 2014-07-04 00:43, Dominick Samperi wrote:
> Hello John,
> I tried to install the Haskell demo Cube on my Nexus 7
> and got: Error: package file was not signed correctly.
> D
>
> On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote:
>> In case anyone wanted
Hmm.. It works on my nexus 4. Kiwamu of the metasepi
http://ajhc.metasepi.org/ is the one that uploaded the demo. Perhaps
he needs to update the key or something.
On Thu, Jul 3, 2014 at 9:43 PM, Dominick Samperi wrote:
> Hello John,
> I tried to install the Haskell demo Cube on my Nexus 7
> and g
On Thu, Jul 3, 2014 at 6:18 PM, Simon Peyton Jones
wrote:
> Luite
>
>
>
> I lack the bandwidth to respond at any technical depth, but I’d like to
> make encouraging noises. If you can figure out a way to make GHC do these
> things without making the compiler terribly complicated and making
> ma
Hello John,
I tried to install the Haskell demo Cube on my Nexus 7
and got: Error: package file was not signed correctly.
D
On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote:
> In case anyone wanted to start writing haskell android code now, jhc
> fully supports android as a target. here is an a
In case anyone wanted to start writing haskell android code now, jhc
fully supports android as a target. here is an app made with it
https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube
this was made with Kiwamu's ajhc branch but code has been merged back
into the main tre
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
This would probably be a great boon for those trying to use haskell for
Android and IOS right? how might the emulation setup work for those?
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,
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 make it run Template H
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 compiled?
It think it w
| 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
On Wed, Aug 3, 2011 at 2:44 PM, Simon Marlow wrote:
> 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 th
On Wed, Aug 03, 2011 at 11:44:10AM +0100, Simon Marlow wrote:
> 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. Inde
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
Hi,
>> 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-consume
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
On Wed, Aug 3, 2011 at 8:56 AM, John Lask wrote:
> 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 disc
On Wed, Aug 3, 2011 at 11:30 AM, Simon Peyton-Jones
wrote:
> Victor
>
> GHC is supposed to be extensible, via its API, so your questions are good
> ones. However, there are things that that the API doesn't support, or
> supports badly, so it is not cast in stone. Please suggest improvements --
Victor
GHC is supposed to be extensible, via its API, so your questions are good ones.
However, there are things that that the API doesn't support, or supports
badly, so it is not cast in stone. Please suggest improvements -- and better
still implement them. GHC evolves largely in response to
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
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.
Ideally pluggable back-ends would be installable as packages.
such infrastructure, I w
On Tue, Aug 2, 2011 at 21:09, Edward Z. Yang wrote:
> Excerpts from Victor Nazarov's message of Tue Aug 02 19:12:55 -0400 2011:
> > But GHC always emit parse error on "javascript" keyword.
> >
> > For now I'm using (abusing) ccall calling convention and simple
> > imports works pretty well, but I
Excerpts from Victor Nazarov's message of Tue Aug 02 19:12:55 -0400 2011:
> I can parse arguments myself
> and throw the rest of them to parseDynamicFlags, but GHC's flags are
> really complicated and I'm not aware
> of any argument parsing library that can be used to filter out some
> specified fl
34 matches
Mail list logo
