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.
> So a symbol is essentially just a name and an exposure specifier. This makes
> it questionable whether CFCSymbol is useful as a base class at all. I lean
> towards eliminating CFCSymbol completely.
I think this is OK. It's always interesting to see how someone else views the
same problem space from a different angle.
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. But it turns out that in the
CFC codebase, all those items are rarely accessed using the CFCSymbol API.
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.
The symbol table could be a hash table mapping `char*` to CFCBase. It's not
necessary for the values in the symbol table to implement the CFCSymbol API.
Marvin Humphrey
