Re: [Chicken-hackers] [MEGA-PATCH] Modularise the compiler!

[Felix Winkelmann]

> I did wonder why you squashed the commits; like I said, I put a lot
> of effort into making them self-contained (and every single commit
> compiles and passes the testsuite).  By squashing them, it becomes
> one big "blob commit".  If this commit introduces a bug, "git bisect"
> will be mostly useless, whereas if the individual commits were kept
> it would give us much more digestible changes.

I don't think that this makes much of a difference, but if you want,
we can split the patch again. But the modularization makes only sense
when applied completely, IMHO.

> OK, I just wanted to put it out there, because the naming and structure
> of the code seems to suggest this was a consideration once.

It was, but is not anymore.

> I'm a little unhappy about the many variables that float around in the
> compiler. 

That's just the nature of compilers - they are complex and have many
knobs to tweak (perhaps too many...) 

> It's a little messy, and it prevents making the compiler
> available as a library (which would be cool if we ever want to make
> an IDE or integrate even deeper with Emacs, or add the ability to compile
> procedures on-the-fly, or whatever.  But that's probably a pipe-dream
> anyway).

Such a change would need considerable restructuring and is in my
opinion not worth the effort. "chicken"/"csc" is a batch compiler, and
is likely to use that model for the time being. Compiling in a
subprocess and dynamic loading is safer, cleaner and less complex,
especially considering the fact that C is not meant to be used in
other ways. Compiling "in-core" or doing JIT-compilation would require
generating native code or some other low-level intermediate
representation, and in the end it would be much simpler just to write
a compiler from scratch (it wouldn't even have to optimize much).

> I was a little unsure about that.  Like I said, I wanted to avoid
> installing the import libraries just yet, because they're just the
> existing stuff wrapped up as modules, not some well thought-out API.
> If we install these import libs and make it an official API, we're stuck
> with the way it works.

Quite right. It's probably better to just have a single exposed module
for the user-passes.

> 
> Maybe one of the first eggs to port would be "bind", as it hooks in
> the compiler so deeply.  That way, we could see what kind of things are
> truly needed and expose just those, as a preliminary official API.

I think we should not think about such an API at this stage, it's
still too early. Some eggs, like "bind" will just have to be kept in
sync with the development of the core system.

> 
> OTOH, maybe this is just too hard to tackle right now.  However, we
> can keep it semi-official by not installing the import libs; it's still
> possible to refer to compiler variables by using the fully-qualified
> identifiers (with the module prefix).

Right.

>>   I would like to change the module names, for
>>   example to "chicken.compiler.<module>". Attached is a patch that
>>   does this. I renamed "compiler.scm" to "core.scm" to have a more
>>   consistent naming of the files and modules
>>   ("chicken.compiler.compiler" just sounded too confusing to me). I
>>   had to change some things in the build for this, perhaps you can
>>   review whether I broke anything.
> 
> I like this.  A lot!  I've pushed this.
> 
> Please note that the aforementioned declaration processing code in
> eval.scm has not been changed: it still reads
> "compiler#process-declaration".  However, none of our tests fail,
> so either it's really unnecessary, or the testsuite is incomplete.
> If it does seem to be needed, this will need to be changed to
> "chicken.compiler.core#process-declaration".

Ah, ok, good catch.


felix