Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

2014-07-05 Thread Scott Turner
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 j...@repetae.net wrote:
 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 tree.

 On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald
 carter.schonw...@gmail.com wrote:
 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
 carter.schonw...@gmail.com wrote:
 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 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 is that Cabal Setup.hs scripts need to be compiled
 to some host-runnable form, but that can also be JavaScript if you have
 node.js)

 Now besides the compiler having to do twice the work, this has some other
 disadvantages:

 - Our JavaScript code has the same dependencies (packages) as native
 code, which means packages like unix or Win32 show up somewhere, depending
 on the host environment. This also limits our options in choosing
 JS-specific packages.
 - The Template Haskell code runs on the host environment, which might be
 slightly different from the target, for example in integer size or 
 operating
 system specific constants.

 Moreover, building native code made the GHCJS installation procedure more
 tricky, making end users think about libgmp or libiconv locations, since 
 it
 basically required the same preparation as building GHC from source. This
 change will make installing much easier and more reliable (we still have 
 to
 update the build scripts).

 How it works is pretty simple:

 - When any code needs to be run on the target (hscCompileCoreExpr,
 through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
 the thrunner.js [3] script,
 - GHCJS sends its RTS and the Template Haskell server code [1] to
 node.js, the script starts a Haskell thread running the server,
 - for every splice, GHCJS compiles it to JavaScript and links it using
 its incremental linking functionality. The code for the splice, including
 dependencies that have not yet been sent to the runner (for earlier
 splices), is then sent in a RunTH [4] message,
 - the runner loads and runs the code in the Q monad, can send queries to
 GHCJS for reification,
 - the runner sends back the result as a serialized Template Haskell AST
 (using GHC.Generics for the Binary instances).

 All Template Haskell functionality is supported, including recent
 additions for reifying modules and annotations. I still need to clean up 
 and
 push the patches for the directory and process packages, but after that, 
 the
 TH code can read/write files, run processes and interact with them and 
 make
 network connections, all through node.js.

 Now since this approach is in no way specific to JavaScript, I was
 wondering if there's any interest in getting this functionality into GHC
 7.10 for general cross compilation. The runner would be a native (target)
 program with dynamic libraries (or object files) being sent over to the
 target machine (or emulator) for the splices.

 Thanks to Andras Slemmer from Prezi who helped build the initial proof of
 concept (without reification) at BudHac.

 cheers,

 Luite

 [1]
 https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs
 [2]
 https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
 [3]
 https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js
 [4]
 https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



 --
 John Meacham - http://notanumber.net/
 

Re: case of an empty type should have no branches

2011-10-10 Thread Scott Turner
On 2011-10-09 07:26, Roman Beslik wrote:
 Why the following code does not work?
 data Empty
 quodlibet :: Empty - a
 quodlibet x = case x of
 parse error (possibly incorrect indentation)

It's a potential extension to ghc.
See http://hackage.haskell.org/trac/ghc/ticket/2431

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: [Haskell] ANN: extcore 1.0

2011-01-13 Thread Scott Turner
On 2011-01-13 14:45, Tim Chevalier wrote:
 Documentation for the External Core format itself lives at
 http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf

Didn't find it there, but did find it at
http://www.haskell.org/ghc/docs/latest/core.pdf

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Type checker's expected and inferred types (reformatted)

2009-10-31 Thread Scott Turner
On Wednesday 28 October 2009 08:14:46 John Lato wrote:
  Isaac Dupree m...@isaac.cedarswampstudios.org wrote:
  ghci:
  Prelude \x - (3+x) + (length x)
 
  interactive:1:15:
 Couldn't match expected type `[a]' against inferred type `Int'
 In the second argument of `(+)', namely `(length x)'
 In the expression: (3 + x) + (length x)
 In the expression: \ x - (3 + x) + (length x)
 
 This is how I understand this process 
 
 1.  checker infers x :: [a] from 'length x'
 2.  checker infers (3 + x) :: [a] from (+) and step 1
 3.  checker infers the second (+) :: [a] - [a] - [a] from step 2
 4.  conflict - checker expects (length x) :: [a] from step 3
  and infers (length x) :: Int from definition of 'length'.
 
 Even with this simple example the error message given doesn't directly
 point to the problem.  I don't think it's uncommon for there to be
 more steps in practice.  I frequently find myself adding explicit type
 signatures to let-bound functions to debug these.  This is a pain
 because it also usually involves enabling ScopedTypeVariables.

I'll second that.

On Saturday 24 October 2009 15:21:51 Albert Y. C. Lai wrote:
I find it unnecessary to decrypt the two words expected and
inferred. They have their own definitions and they stand for
themselves;

On the contrary, this is a perfect example of why the error message's choice 
of words is bad. One type is expected and the other is inferred.  In the 
example the contextual type [a] is inferred via steps 1-2-3, and the internal 
type Int is determined so trivially that the inferred designation is 
somewhere between confusing and misleading. 

I'd love to see expected kept, and inferred removed from the message.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users