Bootstrap notes

[Brian T Rice]

On Tue, 6 Jan 2004, Brian T Rice wrote:

> Well, that covers the VM code per se. It doesn't cover pidgin, my idea of
> a (much nicer) correspondent to Squeak's Slang. Most of that is covered as
> an extension to the C support in src/mobius/c/. The actual code-translator
> is in generator.slate, but it helps to cover the cr.slate files which
> models C program domains, and the types and syntax. Basically what happens
> is that the SimpleGenerator takes some body of code (SyntaxNodes in a
> stream as read from a file, is what I'm assuming so far), and processes it
> into C code, decorating a "program" variable which holds a C Module (which
> is a C file plus directly-relevant header code). The "program" is just a
> huge syntax structure for the output C program, and it gets processed a
> bit before being emitted into strings (onto a File Stream).
>
> What pidgin does is to "flatten" Slate code to a minor extent. All
> dispatch is static, control structures are mapped into C primitive looping
> constructs where possible, and method names and signatures are translated
> to be sensible. I previously mentioned what happens to prototypes; they
> become C struct types.
>
> When pidgin source is read, what happens is that a database is decorated
> with information: what source selector maps to what C function, and what
> Slate type names map to what C struct type names. This database is local
> to the invocation of a C SimpleGenerator, so you have to keep track of the
> output to a C module or (someday, not now) try to mix modules together. If
> there's some ambiguity in the database, it'll throw an error ideally, but
> right now this is not written, so figuring out all the error cases might
> not take as little time as I plan.
>
> About signatures: what happens is that a method definition has its
> selector munged to work in C, which has no multidispatch or Smalltalk
> syntax. So what happens is that the selectors get the name of dispatched
> arguments mixed in to their names at the right point, eg:
>
> "d@(Dog traits) bite: m@(Man traits)" becomes "Dog_bite_Man"
>
> The example works the same way if you define on a specific prototype, but
> that prototype must either have a different name from its traits' name, or
> the programmer gets to hope that they didn't define any conflicting method
> names. Anyway, the function's signature is adjusted to work with those
> types if there is anything relevant. The functions all must be defined on
> integers or prototypes defined within the same source, and the resulting
> types will all be single-word types: either integers and such, or pointers
> to structs.
>
> As a result of this, the static typing is necessary: each function/method
> call has to include casts to the right type for the type-checker to work.
> This is nasty, but from what I can tell, the programmer should not have to
> annotate to do this. I've been considering abusing the ! notation to help
> users add casts manually without too much annoyance; I'll wait to see how
> much can be done with inference (or best-guesses) before then.

Actually, the static typing isn't quite necessary, if I have all
generated functions be defined on ints (which Squeak does) and then cast
internally (which Squeak doesn't... I don't even like thinking about what
Squeak does in this case). But I'd like to do the former if possible.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/