hacks.pod ^

WORKAROUNDS ^

Things that partcl has done that might be considered hacks - things that will likely impair our ability in the distant future to cleanly do language interoperability.

PDD20 - lexical vars

The current scheme (PDD20) for lexical vars means that to be able use the 'store_lex', and 'find_lex' opcodes, you have to be inside a sub that's marked :lex: That is, inside a sub that corresponds to a HLL block that introduces a new lexical scope. Tcl uses helper functions to figure out whether a particular '$a' is referring to a global or a lexical var. We keep track of the lexpads in the 'call_chain' variable and manually look up lexicals in the lexpads.

subroutine meta information.

Tcl provides the ability to query subroutines about their arguments and their code. For example:

 % proc sum {{a 2} {b 3}} {
  return [expr $a + $b]
 }
 % sum
 5
 % info args sum
 a b
 % info body sum

  return [expr $a + $b]

 % info default sum a the_argument
 1
 % puts $the_argument
 2
 %
Right now, partcl is using globals to store the argument list and the body information. It would seem that we'd want to have a builtin mechanism for querying the subs directly rather than storing this information separately.

user defined subs; parameter handling.

Tcl provides nice exceptions for dealing with argument handling - to continue our example:

 % sum a b c
 wrong # args: should be "sum ?a? ?b?"
Right now, this is handled inside the function definition - it is defined to take an arbitary number of args, and then is checked for correctness internally. It would be nice to have invoke() automatically figure this out and generate an exception that Tcl can use. (This also starts to drag in "how to do Tcl exceptions cleanly from parrot")

stack depth

Cheating and keeping a global around right now, so we can figure out if we should be using a global or a lexical (and if so, how far down or up).

[trace]'ing

There are two ways we can go about the tracing - either we can keep the information about the traces in a global, and check that global every time the appropriate action is taken; or, we can tie that information into the actual commands and variables. I think the latter would be somewhat cleaner, and, if any other languages support this feature, this would give us a chance to interoperate.

flush diagnostics

At the moment, there doesn't seem to be a parrot method for determining if a filehandle was opened for reading/writing. We can work around this by tracking it in a hash in the _Tcl namespace.


 parrot