BUKKITs

[Justin Meza]

I want to start thinking about how to incorporate BUKKITs/Objects into
lci for its next major release. There are two important aspects to
this effort: 1. actually getting the code to work and 2. doing so
without breaking or modifying any of the LOLCODE 1.2 functionality.

Both points have their own set of challenges and I want this and other
threads to track the discussion and thought process (even if it's just
me talking out loud :)

[Justin Meza]

I'm leaning toward this specification for BUKKITs: http://lolcode.com/proposals/1.3/bukkit2
(discussion thread here: http://forum.lolcode.com/viewtopic.php?id=431).

I like it because it also addresses the function ambiguity issue.

BUKKITs are at the core of the template-based OOP in LOLCODE so there
will need to be close coordination between BUKKIT implementation and
object implementation.

[Justin Meza]

Going through the list of proposals in the spec, here are some
possible implementation strategies (each of which represent a mini-
project):

1. Memory: it might be nice to add a static variable liveness check
module to the pipeline. Special GC nodes could be added to the parse
tree that free variables which are never used again after that point.

2. Declaration: implementing "ITZ A <type>" is fairly simple and
involves adding some type information to the declaration statement
node. (I.e., in this version of the code, adding a TypeNode field to
DeclarationStmtNode.)

3. Deallocation: since NOOB is not an expression, it will not parse
with the current grammar. It makes sense to just parse "R NOOB" as a
completely new token (TT_RNOOB) and add it into the parse tree as a
new stmt node type (DeallocationStmtNode).

4. Primitive types: I *think* this is already handled because of the
way the interpreter is written.

5. SRS cast: this is interesting and will be fun to implement. I
think the easiest way would be to add a flag to the IdentifierNode
structure called "indirect" which is zero if a normal variable access
and non-zero if an indirect (SRS) variable access. Then, I would
change interpretIdentifierExprNode in interpreter.c to check this flag
and, if non-zero, cast the identifier to a YARN and then look it up in
the symbol table.

6. FUNKSHUNS: we need to change the function call syntax slightly and
tokenize the question mark (TT_QUESTION) and check for it when parsing
functions. Also, MKAY must be used to remove ambiguity from the
grammar (we can then remove the current function table builder step
from the pipeline).

7. BUKKITs

There is a lot to be done here but here is one idea: modify the
ValueData union to have another field for BUKKITs, a ScopeObject *
pointer to the contents of the BUKKIT.

Because BUKKITs can hold functions, an additional ValueData field must
be a FuncDefStmtNode * pointer. The grammar is currently parsed to
retain scope data (e.g., in "<scope> HAS A ..." the
DeclarationScopeNode stores "<scope>" in the "scope" field) but this
needs to be incorporated into the interpreter to reference the correct
scope at runtime.

The inline BUKKIT declaration can be accomplished with some new tokens
(TT_OHAIIM, TT_IMLIEK, KTHX) and a new parse tree node like:

typedef struct {
IdentifierNode *name;
IdentifierNode *parent;
BlockNode *body;
} StructDeclStmtNode;

To access BUKKIT slots, we need a new token (TT_HYPHENZ) and a new
expression node:

typedef struct {
IdentifierNode *parent;
IdentifierNode *target;
} MemberAccessExprNode;

I think the sections starting with "Special Slots" need to be
revisited and potentially revised. Completing the above would add a
lot of functionality to the interpreter.

(Note that if changes are made to the grammar, please update the EBNF
in parser.h accordingly.)

I think that making a single binary compatible with both 1.2 and 1.3
could get really messy because 1.3 modifies some of the functionality/
grammar of 1.2. I think it would be a good idea to have a new
"unstable" branch for 1.3 and maintain 1.2 and 1.3 separately. Any
thoughts on this?

[Justin Meza]

So, a bit of an update on my efforts and next steps. A separate post
mentions the "future" branch has been created for working on 1.3-
related changes and currently contains variable type declaration (ITZ
A) and variable value deallocation (R NOOB).

The way I set out for implementing the SRS cast is not correct as it
only supports one level of indirection. The correct solution is to
create two identifier types: IT_DIRECT and IT_INDIRECT. Direct
identifiers act the same as current identifiers but indirect
identifiers (signaled by SRS) contain an ExprNode member (which itself
may be another indirect identifier). Incidentally, it will be easiest
to rid of the current function table (by implementing the 1.3 function
proposals) in order to implement SRS because the function table
currently relies on grabbing identifiers as the basis for function
names and if identifiers depend on the function table then there is a
cyclic dependency... this probably does not make sense but suffice it
to say SRS will be more easily implementable after 1.3 functions.

I am currently working on function definition--an addendum to my
earlier description: no question mark token is needed as that was just
part of the regular expression used to describe functions. I have a
couple of nits with the current definition:

1) HOW IZ is not as canon LOL-esque as HOW DUZ
2) Calling syntax is excessively verbose requiring YR and AN YR in
between all arguments... I plan on making these, like for built-in
functions, optional.

That leaves BUKKITs--Glen, if you're up to it, I think this would be a
great place to do some (very useful!) work. It would be nice to plan
it out in a bit of detail on the mailing list and to first try
implementing BUKKITs that only hold built-in datatypes (i.e., not
functions) until the 1.3 functions are in place.

Let me know what you think.