Hi Matthew, Although it doesn't "really" answer you question, you could take the same approach as I did with CLaSH (http://clash-lang.org/) which translates Haskell to VHDL/(System)Verilog. Although I didn't want to "expose" VHDL/(System)Verilog terms and types per sé, I guess you could see it like that in a way. Let's take a look at the BitVector type (http://hackage.haskell.org/package/clash-prelude-0.10.13/docs/CLaSH-Sized-In...) for example. = Exposing data types = You could, in a way, say that the BitVector type, and its operations, are the "exposed" std_logic_vector/bitvector types and operations of VHDL/(System)Verilog. So, I "exposed" the bitvector/std_logic_vector type as:
import GHC.TypeLits
newtype BitVector (n :: Nat) = BV {unsafeToInteger :: Integer}
Now, there are, using newtypes can be a bit "dangerous" as GHC will have the tendency to coerce between newtypes and it's underlying representation. That, and if you use https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/ghc-8.0.1/Type...., you might accidentally look through the newtype. So, perhaps a safer way is to just do:
data BitVector (n :: Nat) = BV {unsafeToInteger :: Integer}
Also, I use 'Integer' as the underlying representation because I want to "simulate" my circuits in Haskell. However, if you dont't care about this, you might as well use '()'. = Exposing functions = You mentioned that GHC does name mangling, but I must say I've never seen GHC do this. What GHC does do is inlining and specialisation, which might optimise away your carefully constructed "primitive". What I do in this case, is simply mark my "primitive" function, your "exposed" BlueSpec functions, as NOINLINE. For example, I define equality on BitVector as:
instance Eq (BitVector n) where (==) = eq# (/=) = neq#
{-# NOINLINE eq# #-} eq# :: BitVector n -> BitVector n -> Bool eq# (BV v1) (BV v2) = v1 == v2
{-# NOINLINE neq# #-} neq# :: BitVector n -> BitVector n -> Bool neq# (BV v1) (BV v2) = v1 /= v2
Again, I want to "simulate" my circuits, so I've given actual definitions for my operations. But if you don't care for this, you can simply leave them as 'undefined'. = Wrapping up = So I hope it's clear how to "expose" target terms and types through simple data type wrapping and the use of NOINLINE. You'll have to do the above for all the BlueSpec data types and functions you want to expose and then package it up. Perhaps also, if you have the time, using BlueSpec's FFI and Haskell's FFI, you could hook up the "exposed" operations to BlueSim, and have "co-simulation" between Haskell and BlueSpec. Anyhow, I hope this helps. Let me know if you have any more questions. Regards, Christiaan On 08/24/2016 02:05 AM, Matthew Farkas-Dyck via Glasgow-haskell-users wrote:
A colleague and i are writing, as an unofficial side project, a Haskell→Bluespec compiler, using GHC as our Haskell front-end. The source language of the part we are writing is GHC Core. We need to somehow expose some Bluespec terms and types to the Haskell source program. We had a few ideas: 1. Some "NO_MANGLE" pragma which would tell GHC to not mangle the emitted name, e.g. `x = {-# NO_MANGLE #-} x` to expose `x` 2. `foreign import prim`, not quite sure how yet 3. "CORE" pragmas, e.g. `x = {-# CORE "foo" #-} x` to expose `x` 4. "ANN" pragmas, e.g. `{-# ANN x "no_mangle" #-} x = x` to expose `x`
1 and 2 would mean modifying GHC which we'd rather not do. For 3, we're not sure how to find the "CORE"-pragmatic annotations in a `Core` AST. 4 seems it would work but be a little cumbersome, as the annotation is not on the `Core` AST.
Anyone know a good way to do this? _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users