Some questions about the current implementation

[pluckyporcupine]

Apologies for submitting this as an issue. I wasn't sure where else to ask.

I'm interested in working with Habit, as I've been trying to find a good solution for lower-level functional programming, and I had a few questions, as I'm unsure whether the docs in /doc are relevant to the current implementation, as many of them haven't been updated in 3 years.

1. Is there still an FFI of sorts? If I'm understanding /doc/primitives.txt properly, simply defining a reference to a function and then building that function in C and linking the object file built from your C file will allow you to use functions from C? However, I see that the documentation for calling Habit from C also mentions building with CompCert and something called "cheney" that I can't seem to find on the web easily, while the Makefile has explicitly removed references to CompCert, but what appears to be an example of using an FFI in /tests also remains largely unchanged, so it's unclear to me whether that still works the same way or how I would go about using such features.

Which leads me to...

2. Is CompCert required to use Habit or is everything based on LLVM now, as per usage of mil-tools?

3. Are linear and substructural typing, described as "a more experimental feature of Habit" on habit-lang.org, implemented?

Thanks in advance!

[peschkaj]

CompCert is no longer needed, everything is built using LLVM. You can link to anything that LLVM can turn into a .o file.

You will need to build mil-tools and get that working on your machine. After mil-tools is built, there's a milc script that you can throw somewhere on your path. You'll also need to modify the milc script with the path to your mil-tools installation, but that should be what you need.

I'm not sure about the experimental typing features, so I will leave that to someone else, like @jgbm or @apoorvingle, to answer.

[pluckyporcupine]

Thanks. So do external functions, as in the examples, work the same way or is something else needed to call functions from the linked .o files that are compiled from code in other languages?

[zipwith]

Here's a simple but complete example to illustrate how the process works at the moment. Please understand that much of this is still in a preliminary state; there is still a lot of work to be done to make all the pieces work together more easily.

First, here is a simple C program that contains the definition of a printNum function:

    $ cat printNum.c 
    #include <stdio.h>
    
    void printNum(int n) {
      printf("printNum(%d)\n", n);
    }
    $

Note that we're using an int argument here because the prelude currently defaults to 32 bit; if we were using a 64 bit prelude, then we'd want to use a long argument.

Now we can compile with gcc -c to generate an object file using -m32 to select 32 bit mode:

    $ gcc -c -m32 printNum.c
    $ 

Now we want to write some Habit code that will use our printNum function. For starters, I'll create a .milc file in the working folder to set the parameters that we need for 32 bit in the back end of the Habit compiler (aka mil-tools and LLVM); this requires some details that are specific to the macOS machine that I'm working on here and that will need to be changed on other machines.

    $ cat .milc
    # This is a simple .milc file
    # Generate 32 bit code:
    --32
    
    # LLVM target triple:
    --target=i386-apple-macosx10.14.0
    $

Next up, we need a Habit program that will use our foreign function example:

    $ cat ffex.hb 
    requires prelude
    
    primitive printNum :: Unsigned -> M ()
    
    main :: M ()
    main  = do printNum 10
               printNum 32
    $ 

Now we can use alb to compile the Habit code to LLVM:

    $ ./alb --Sl ffex.hb 

And then we can link the generated LLVM code with the previously generated object code for printNum. The error message here is just because Apple is deprecating 32 bit development on macOS.

    $ clang -o ffex -m32 ffex.ll printNum.o 
    ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
    $

Finally, we can run the whole thing:

    $ ./ffex
    printNum(10)
    printNum(32)
    $

I hope this gives you a good overview. Right now, this whole process is more complicated than it should be, and it's critical to get the right configuration settings all the way through to avoid mysterious failures. We're working to address that, and are happy for you to experiment with alb and related tools ... just so long as you don't mind being on the "bleeding edge"!

[pluckyporcupine]

I don't mind being on the bleeding edge at all. As long as I can get it functioning, I'm alright with a little extra configuration work.

So it does work as it does in the tests, then. The process actually doesn't seem too complicated in the sense that it doesn't take much to wrap functions for use at all.

A few more questions about the FFI, just for my edification:

• Is it possible to, say, work with C pointers in Habit's current interop implementation? Trying to get a grasp of what's possible.
• While it is possible to "link to anything that LLVM can turn into a .o file," can Habit interop with anything or only C?

Also, in regards to the prelude defaulting to 32-bit, is there a 64-bit prelude?

[zipwith]

A few quick responses:

• In case you're not already aware, "bleeding edge" includes the fact that, while you can write your own allocator, there is currently no support for garbage collection ... we are currently focussed on applications that do not require GC.
• In principle, yes, it should be possible to work with pointers, passing them back and forth between Habit and C. In practice, I'm not sure anyone has tried to do much of that just yet.
• Our backend generates LLVM code; there's nothing C specific about it. But again our experience is limited. So far, I think we've only linked against code written in C, assembly, and LLVM. Again, our primary focus is on applications written primarily in Habit that occasionally need functionality that is implemented in an external low-level language (so as to get direct hardware access, for example).
• You'd have to edit/replace the current prelude to make it suitable for 64-bit work. In principle, that should just be as simple as replacing occurrences of 32 with 64. I'm not sure why the current prelude doesn't use a single type WordSize = ... definition to set the WordSize and then use WordSize everywhere else instead of a constant. It could be that doing so exposes (or, at some point, exposed) a bug in the implementation. But it might also just be a reflection of the way the code has evolved. As of a couple of weeks ago, the back end has a mechanism for setting the word size based on a command line flag. I expect the front end may do something similar at some point, but I don't think that is a top priority.