On 22/04/2015 02:59, Marvin Humphrey wrote:
On Mon, Apr 20, 2015 at 1:21 PM, Nick Wellnhofer <[email protected]> wrote:
The original motivation came from thinking about how to reimplement the
Clownfish compiler as a Clownfish project itself.
I was thinking a bit more about this recently. I wonder if it makes sense to
have a small compiler implemented in C -- just enough to compile the
`clownfish` package, and then use that to bootstrap a full compiler
implemented as a Clownfish project.
Well, a compiler for the Clownfish package has to support almost all Clownfish
features. I don't think it would be very small, but look very much like CFC in
it's current form.
The rationale for CFCSymbol as a superclass was that classes, inert variables,
inert functions, and methods (or at least their implementing functions) all
live in one global namespace as unique symbols.
Do they? The way I see it, only classes live in a global namespace, and
variables and callables (functions and methods) live in a class's namespace.
That's why I wouldn't make CFCClass inherit from CFCSymbol.
One way that CFC could be improved is to use a symbol table to manage scope
and detect collisions.
http://www.tutorialspoint.com/compiler_design/compiler_design_symbol_table.htm
Even though the Clownfish header language allows very little nesting, in
retrospect it would be better to use a symbol table instead of scattering the
symbol scoping logic over various registries and type internals.
I don't think that symbol tables would buy us much except for detecting name
clashes between variables and callables.
Anyway, there are some commits in my cfc_symbol branch that I definitely want
to merge:
- micro_sym/macro_sym cleanup
- CFCCallable base class
- CFCMethod_is_fresh helper
Nick
