[bitc-dev] Progress report

[Jonathan S. Shapiro]

On Mon, 2006-06-19 at 17:50 +0200, Tom Bachmann wrote:
> - - in the relnotes (yes, I know they're not yet current) you state:
>   "This [new default program entry point is bitc.main.main] has the
>   additional advantage that argument types for main need not be
>   explicitly specified in the source"
> 
>   Either this statement or bitcc is wrong:
>   source:
>   ;copied from the unit tests (original file compiled cleanly)
>   (bitc-version "0.10")
>   (provide main bitc.main)
>   (import stdio bitc.stdio)
> 
>   ;(define (main.main argVec:(vector string))
>   (define (main.main argVec)
>     (stdio.write-char stdio.stdout (stdio.read-char stdio.stdin))
>     (stdio.write-char stdio.stdout #\{linefeed})
>     (the int32 0))
> 
>   compiler output (gcc):
>   bitc.out: In function `main':
>   bitc.out:339: error: `K_6string' undeclared (first use in this
>    function)

Better would be to say "untested". I took Swaroop at his word on this.
I'll check with him when he returns tomorrow. Thanks!

> - - bitc_string_lenght seems to be declared extern, but no implementation
>   is provided - should I link one more library? (this is at least my
>   speculation, substitute with a better description)

Not yet. I'm in the process of working on this, and...

Now *that* is *truly* irritating. It looks like an entire .c file was
lost at some point and I will need to recreate it. Blast. Fortunately it
wasn't big.

What happened was that I got distracted chasing down some other bugs
while I was working on this.

> - - is closure conversion implemented or not? I still have the example
>   here where you said it needs closure conversion, and it still does not
>   compile.

Closure conversion is implemented, but there appear to be some bugs in
the typing. Try pulling the very latest (there were some checkins last
night). Run the compiler by hand with the --showpasses option. To
confirm that closure conversion is (or is not) happening, you should be
able to use

bitcc --dumpafter polyin --dumpafter clconv ...other-args...

and then examine the procedurein question. Unfortunately, all of the
examples that actually use closure conversion appear to be failing at
the moment in the type checker, and it's happening in a part of the
compiler that I do not know enough to fix (which is why this needs to
wait for swaroop). The fix will be very quick, but I don't want to break
anything by messing with it.

> - - also, you state in the release notes that you are looking for a bsd
>   licensed arbitrary precision integer math library. I'm not aware of
>   any, but gmp is lgpl'd, if that helps.

Doesn't help. No final decision yet, but we really want the option to
BSD license this work.


shap