[jhc] Emitting Optimal C

[Rick R]

Thanks for that info. The iPhone app and the bayes stuff are separate.
I will likely use jhc for for the bayes stuff.  Once I get to the
point where I'd like tight C++ integration, I'll be sure to yell.

However, for the iPhone, Pre-Scheme fits my needs almost perfectly.
Since Apple can (and does) reject apps for any reason, I would like to
make my apps as conformant as possible. Which building C/Obj-C start
to finish within X-code, only statically linking, and only using their
libs.
Dynamically linking is expressly forbidden, and GC is a gray area in
which I'd rather not tread.

On Mon, Feb 23, 2009 at 6:44 PM, John Meacham <john at repetae.net> wrote:
> On Sun, Feb 22, 2009 at 11:44:25AM -0500, Rick R wrote:
>> I have been looking for a functional language that compiles to efficient
>> C/C++ to fufill two rather odd criteria.
>>
>> 1. To conform to the requirements of the iPhone Developers Program. Code
>> must compile in XCode and be either C/C++/Obj-C. Garbage collection is
>> mostly disallowed. Program size and memory must fit below a threshold.
>
> Hmm.. interesting. What compiler is XCode based on? If it is a gcc
> derivitive, I don't see any reason this wouldn't work. It is actually
> quite easy to compile programs for OSX or windows with jhc
> if you have something like IMCROSS[1] installed. you just do
>
> jhc --progc i386-mingw32-gcc HelloWorld.hs -o hello.exe
>
> I was able to compile programs for the iPhone the same way, but I had a
> jailbroken phone so didn't need to conform to their other standards.
>
> I am not sure what they could mean by 'no GC', is it simply because they
> require C/C++ or ObjC? I mean, when you write a C program, clearly you
> need to write in some mechanism to deal with garbage.
>
> Hmm.. you might want to ask them whether it is okay to link against the
> boehm gc.  although not ideal (very not ideal speed-wise), jhc works
> with that, but if they allow it, then I imagine the more advanced gc
> options will be okay too.
>
>
>> 2. Separately, to perform Naive Bayes computation across huge datasets. What
>> is required is function inlining as well as use of SIMD instructions.
>> I would provide the inlined functions via .h's and compile them in with gcc.
>
> How huge of a dataset? Are you working on a better song recommendation
> wizard? Something you might want to look into is that I am pretty sure
> the iPhone has sqlite as standard equipment, I think you can extend it
> with your own operations, perhaps a bayes computation operation or
> something. hmm... but the sqlite overhead might kill you. hard to say.
>
>> I see that jhc see offers a way to specify unboxed values and tuples. And
>> I'm sure there is a way to manage large native arrays as well. Is there a
>> way to pass that data directly to an inline C function that would be
>> compiled in by gcc? (i.e. not loaded from a library through FFI)
>
> When you import something via the FFI, say something like
>
> foreigin import ccall foo :: CInt -> CInt
>
> then nothing special happens other than calls to foo(x) will appear in
> the source. now, you can provide that function however you want, via a
> library, or via direct linking against the C code, jhc doesn't really
> care.
>
> Hmm.. if you want to actually have them be inlined functions, I will
> probably have to give you a way to specify that the definition actually
> might appear in the header file, not just a prototype (since prototypes
> arn't needed in general) so a pragma might be in order to say "I really
> need this file #included.". It should be easy to implement. When you
> come across the issue post it on the list and we can figure out what the
> best solution is. A trivial workaround would be to just postprocess the
> c code produced by jhc itself until a built in mechanism is created.
>
>
>> I've looked through most of the jhc mailing list archives and haven't found
>> any such discussions. Would this be something that would be achievable
>> somewhere in the jhc roadmap, or at least conceivable with a few hacks?
>
> Nothing sounds like a showstopper. jhc is great at cross compiling, so
> embedded targets like phones are a natural match with it.
>
>        John
>
> --
> John Meacham - ⑆repetae.net⑆john⑈
> _______________________________________________
> jhc mailing list
> jhc at haskell.org
> http://www.haskell.org/mailman/listinfo/jhc
>



-- 
We can't solve problems by using the same kind of thinking we used
when we created them.
    - A. Einstein