[haskell-llvm] Limitation of API - omissions or design?

Maciej Piechotka uzytkownik2 at gmail.com
Thu Dec 16 07:47:23 EST 2010

On Thu, 2010-12-16 at 05:51 +0100, Henning Thielemann wrote:
> Maciej Piechotka schrieb:
> > I tried to use Haskell + LLVM binding to it to write university
> > compilers assignment and I run into some problems with API:
> > 
> >  - Many functions are non-existing or not exported.
> It's also a problem of LLVM that not all LLVM functions are exported by
> the LLVM interface to C. Haskell can only call the C interface, not the
> C++ one.

I meant by the functionality of low-level api. At least things like
greating global from CodeGenFunction scope.

> > For example it seems
> > to be not possible to create array containing other things that 0 and -1
> > other then String.
> I have already successfully worked with arrays. Can you please show a
> piece of code that does not do what it should?

Now that I know that constOf is exported (I missed it from export list)

> > The constOf function is also not exported.
> The constOf function is exported, but for some unknown reason Haddock
> does not show it.


> >  - Higher API enforces type safety, which is good thing if one uses LLVM
> > to DSL - however if LLVM is used as backend it causes problems as I
> > don't know types at compile time and checking is part of other part of
> > code.
> You can use Rank2Types in order to construct Haskell types at runtime.
> The technique is illustrated by converting a Haskell number to a Haskell
> type level number:
> http://hackage.haskell.org/packages/archive/type-level/0.2.4/doc/html/src/Data-TypeLevel-Num-Sets.html#reifyIntegral

I use this technique often. Well the code is secure but I have things
like infinite space of values of infinite space of functions.

Possibly I am doing something wrong but there is small amount of
examples on web.

> > GADTs allows workaround problem but
> >  - Higher API cannot jump into lower API for a few instructions but uses
> > all-or-nothing approach. Normally it would be good thing if not the
> > previous problems.
> Maybe if you show a specific problem we can turn Nothing to All. Note
> that there is another Haskell LLVM interface that, as far as I know, is
> not as strongly typed and is used for the GHC LLVM backend.
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM

Unfortunatly targe compiler is GHC 6.12.x not 7.0.x

Thank you

PS. I'm sorry for the content of list but it was sent on 4am after whole
day of trying to understend LLVM.

PPS. I'm not sure how to solve this problem - it is separate to the
above issues. On Gentoo there seems that MISP target is not built even
with alltargets USE flag:

ghci> x <- newModule
Loading package syb-0.2.2 ... linking ... done.
Loading package array- ... linking ... done.
Loading package containers- ... linking ... done.
Loading package pretty- ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package type-level-0.2.4 ... linking ... done.
Loading package mtl- ... linking ... done.
Loading package bytestring- ... linking ... done.
Loading package filepath- ... linking ... done.
Loading package old-locale- ... linking ... done.
Loading package old-time- ... linking ... done.
Loading package unix- ... linking ... done.
Loading package directory- ... linking ... done.
Loading package process- ... linking ... done.
Loading package llvm- ... linking ...
<interactive>: /home/mpiechotka/.cabal/lib/llvm- unknown symbol `LLVMInitializeMSILTargetInfo'
ghc: unable to load package `llvm-'

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://projects.haskell.org/pipermail/haskell-llvm/attachments/20101216/138fac6e/attachment.pgp 

More information about the Haskell-llvm mailing list