[anic] status?

[Daniel Kersten]

Hi all,

I had a look at the changes on the google code page, but find it hard to stay on top of how anic is progressing fromt hat, so I'll ask instead.
How is anic coming along and what has been done/is left to be done?

As always, I'm volunteering to help, but feel very lost when it comes to actually doing something, so if theres any tasks that can be handed out (and explained well enough that I could do it..), I'd be ahppy to help.

Regards,
Dan.

--
Daniel Kersten.
Leveraging dynamic paradigms since the synergies of 1985.

[Adrian]

I'm still toiling away at it ;). Actually, I'm in a career shift at
the moment, with some very classy and important interviews in the
coming week, so naturally pet projects need to come second.

There's actually two branches to the source now; the default one
builds clean but is kind of old, and main development is happening on
a fork meant to experiment with a new, much more object-oriented type
system. The new branch won't build at this point, since I gutted a lot
of the semantic analysis in the hopes of making everything cleaner
going forward. However, the build errors are (I believe) entirely
confined to semmer.cpp, where typing functions complain about #defines
that I removed (these errors are actually extremely useful, though,
since they spell out exactly which functions need to be looked at /
reimplemented).

So I'm still annotating the parse tree/symbol tables with type info,
and the work is mainly in walking through the syntax tree and
constructing the right types for everything (quite literally
constructing, via specialized Type subclass constructors). Other than
that, the inter-type interactions are all implemented. For example,
Type::operator>>(Type&) will derive the result of sending any type
to / filtering it through another, including flagging invalid flows by
returning an error type (defined by global variable Type *errType).
Type::operator==(Type&) tests type equality, operator!() tests for the
error type, and so on.

If you know a thing or two about type systems and have a grasp of how
ANI works (which you've demonstrated countless times that you do!), a
leisurely walk through semmer.h and semmer.cpp will hopefully make it
clear what's going on, and I'd be glad to explain any details that
people aren't sure about. The hardest part would be understanding the
syntax tree structure (defined in parserGrammar.y) and walking it,
because it's heavy on context-sensitive pointer fiddling (for
efficiency's sake). Still, there's nothing surprising about the code
if you've implemented nontrivial data structures in C, and once again,
I'm more than happy to clarify the muddy parts should there be any.

This really is the most critical part of the compiler, though: once
you have types flowing from point to point, overloading
Type::operator>>() to return assembly dumps instead of Type objects is
largely mechanical. Thus I'd prefer to get this right on the first try
rather than having to redesign the language/grammar at a later point.

I'm actually really looking forward to working with you, Dan; we seem
to be on the same page with most things, and you've shown countless
times that you simply "get it" with the language and its raison
d'etre. We just need to get this ball rolling ;)!

Either way, anic is my prime (and currently only) pet project and
there's no way I'm going to let it slip away after having come this
far, in case anyone had any doubts ;). In fact I'd love to work on
anic full-time, but for the time being I need to focus on other ways
of procuring the electricity, internet access, and coffee that the
project demands.

Adrian

> --
> Subscription settings:http://groups.google.com/group/ani-compiler/subscribe?hl=en