Entry point and C main function

[j-hui]

We already know the entry point of the SSM program based on what is passed to compile. And that entry point should be invoked in the C main function to put it in the continuation queue, before calling tick for the first time.

There are two related questions to discuss:

1. Where should the main function be? Should it be generated from the Haskell codegen, as we currently do for the trace platform, or should it be part of the platform code? I'm an advocate for the latter approach, since there's a lot of platform-specific boilerplate involved, but relatively little SSM program-specific information.

2. What should the interface to the SSM entry point look like? As in, what should its type signature be? The simplest answer would be to keep it as SSM (), which is what compile already expects. But this doesn't support any kind of arguments or return value, which are primitive but valuable ways of interfacing with the environment.

[sedwards-lab]

1. The C main() function should be part of the platform code, but it should be possible for the user to easily override it. If we want to keep generating custom main() functions for the trace platform, it should be possible.
2. We'll probably want to make the interface platform-specific

[j-hui]

@sedwards-lab and I discussed adding a ref u8 parameter to the prototype of the main function, that would act as a sort of "stdout" to the program. So instead of main :: SSM (), it might look something like main :: Ref Int -> SSM (). Each platform's main entry point (which invokes SSM's main) could do some platform-specific output whenever that reference is written to.

This could be very useful for testing (both automated and manual), because it would effectively allow the user to print, using the language's existing capabilities.

Of course, we can consider adding additional parameters; in particular, for standard input (CC @hmontero1205 ).

[Rewbert]

How would this look in a program? Would this stdout 'handle' need to propagate from the entry point to any procedure that might write to it? It would be nice if we could do this while avoiding such boilerplate passing-around of that parameter. I am sure we can put something nice together.

[sedwards-lab]

It depends on our variable scoping rules. I don't know that we have anything other that function parameters and function-local variables, but we could have global variables or perhaps even nested function declarations (a la Haskell).

[Rewbert]

I already added support for global variables on one of my branches (the one with the led/button example, those variables are declared globally). I could try to make a pr with just that change if you'd like to take a look? :)

[j-hui]

Closed in #46 and #50