The next *big* milestone is to be able to run tcl's test suite natively.
That means being able to deal with all the commands in:
http://cvs.sourceforge.net/viewcvs.py/tcl/tcl/library/tcltest/tcltest.tcl?view=markup
This will require a lot of work.
On the plus side,
we'll be passing a lot more tests by then.
=-)
- pbc_merge
- Take advantage of the new
pbc_merge
to combine the various .pbc files into a singleton.
- Makefile deps
- Should be more explicit about the PMC dependencies in the makefile.
*something* is causing things to get rebuilt unecessarily each time "make tclsh" is run.
- keyed access
- tcl is not using Keys when getting from aggregates.
It probably should,
at least for language interoperability.
- implement default globals,
etc.
- global variables provided by tcl libary.
tclvars.
- global variables provided by tcl interpreter.
tclsh
- source per-user settings.
tclsh
- provide a way to access existing library PIR from Tcl.
- Perhaps via [namespace import]?
Can fake it right now with [inline]
- [expr]
- Add "is_const" global which checks to see if something is,
in fact,
constant.
(which will allow us to then constant fold)
- TBD: ternary op
- TBD: functions that take > 1 arg.
- TBD: Argument type requirements - Currently works ONLY on bitand - esp need to get any that require int-only args,
as we can now /generate/ floats,
even if we cannot specify them.
This is all supportable by MMD - we just need to specify the correct errors to throw.
- [regexp],
[regsub],
-regexp
- Don't have a tcl-style RE PGE class avaialable yet.
- [pwd],
[cd] [#???]
- Need this to run tcltest
- [interpinfo name] [#36277]
- how to do this from inside parrot?
Design issue: what's the right answer?
if we're called as
parrot tcl.pbc foo.tcl
,
do we report just parrot
,
or parrot tcl.pbc
?
- [split]
- There's already a split opcode that should do most of what we need,
except it's not quite finished yet.
- [after],
[vwait]
- pending the event system thunk.