After talking to subbu we will make an IdentifierOperand for this case (and also use it in the other places where we know we are working with identifiers). This is useful in pointing out the real type of what the argument represents. It should also make it easier for the compiler to generically compile this operand type without having to put special logic in each instr which needs it.
In further discussions we also talked about the idea of whether all arguments should be operands or whether they should be a mixture of Operand-derived types (this is our current reality). Based on past experiences with memory issues of the AST, it seems like this may be one reason alone to continue with a mixed operand/non-operand arg list. Other reasons we talked about: 1. Cost of boxing from a time perspective. Not huge but a cost. 2. Cost of analysis walking over operands that nothing will never care about. Also not a huge cost. Reasons for all operand-derived operands: 1. Consistent typing for systemic processing. A dumper can literally just walk each operand and dump it and the need of per-instr processing is reduced/eliminated 2. #1 re-stated...less specific impls of various methods on each instruction type. Ultimately, this is a classic trade-off scenario. We have already moved to a mixed environment without actually mentioning it. This means more instructions will be responsible for making sure all logical operands are processed properly (compiling/interp/analysis), but it also means we can do less work by not casting everything in one big "extends Operand" stroke. -Tom On Mon, Apr 9, 2012 at 8:44 AM, Thomas E Enebo <tom.en...@gmail.com> wrote: > I think the main issue is they need to be encoded as some sort of > operand. We need to be able to dump/load instructions. We could > create a special operand for this maybe? > > -Tom > > On Sat, Apr 7, 2012 at 5:21 PM, Charles Oliver Nutter > <head...@headius.com> wrote: >> I'll reply to this with notes as I go. >> >> AliasInstr has operands that are StringLiteral. The arguments to an >> alias can never be a Ruby String, they can only ever be a simple token >> (alias foo bar) or symbol-like tokens (alias :foo :bar). I don't think >> the operand should be a string literal, since we don't use it as such >> and it can't actually be a Ruby string. For now, I'm using the >> internal .string value in the compiler. >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > > -- > blog: http://blog.enebo.com twitter: tom_enebo > mail: tom.en...@gmail.com -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
