LadyCailin

In my example #1, I think that's a compelling use case, but that's within the same file. But you could just as easily break that into a separate file with...

Not necessarily. Consider the case where it logically makes sense to define it in different files, perhaps if you're replicating like a stubbing system.

I'll add to this that it's starting to get to the point where the compiled files should also be serialized and output to the file system. Even something dead simple...

Here are my thoughts: In general, I expect the following: ```java proc _a(@a = whatever()) {} ``` to be equivalent to: ```java proc _a(@a) { if(unset(@a)) { // where unset...

comp_execute is a straightforward thing to implement, and can be done with little effort, and would be in general a replacement for your use case (and indeed a better replacement,...

Hmm, yes, variable usages. Here's how I envision it working, let me know if you have a different opinion: Consider: ```java @b = array(); proc _myProc(@a = @b) {} ```...

Hmm, that's true. However, I think changing that behavior is too much, so we should support that anyhow. It would be nice to keep environment cloning to a minimum, but...

Yes, that's true, so that may not be possible then. Either now, or at any point in the future, perhaps. But that still leave the question then. I guess cloning...

I would like to attach a (suppressable) compiler warning if dynamic includes are used, with basic information about what kinds of error they may cause, so that things like this...

Base this commit off of the genericsTake2 branch. I kept making signature changes to typecheck and getReturnType, and I got tired of changing that everywhere, so I just made those...