Tests
-----

- Perl Inline::SLang::Struct_Type objects to S-Lang structs:
    Leak memory (converting the other way seems okay [is this really
    true/supported?])

- S-Lang Assoc types to perl:
    add support for arrays, any_type

- Memory leaks:
  Have started leak tests but it's not been comprehensive.

S-Lang to Perl
--------------

  - work out how to "support" unknown types: can we use a perl
    object (Inline::SLang::OpaqueType say)? To do anything with it you
    would have to pass it back to a S-Lang function - so like
    the current design of the Inline::SLang::Ref_Type object.
    As an example:

      my $reg = regParse( "circle(100,200,20)" );
      reg_some_other_routine( $reg, ... );

  - improve the support of 1D & 2D arrays
  - add support for nD arrays
  - use PDL

 Functions:
  - handle reference types; are there others that are needed?

 Variables:
  - do we want to allow access to S-Lang variables (ie have them
    bound to a perl 'lvalue' routine)?

Perl to S-Lang
--------------

 - most of it needs to be done!

General
-------

 - decide how to handle errors.

 - how do we support PDL? Should there be an option to convert
   arrays using one of:
     plain perl, return as a single 'string', as a piddle

 - improve documentation

 - do we allow users to 're-bind' the S-Lang interpreter during
   a program: ie program loads and S-Lang is bound to Perl; user
   does an eval in S-Lang to create a new function and wants that
   available from Perl, so they'd want to 're-bind' things. This
   wouldn't be automatic (too slow) so they'd have to request this.
   And the function(s) wouldn't be available the next time the
   script were loaded (ie not saved as part of the cached code)

Compilation
-----------

If a user says

  use Inline 'SLang' => <<'EOS1';
  ..
  EOS1

  use Inline 'SLang' => <<'EOS2';
  ..
  EOS2

perhaps with some configuration changes in between,
do we create 2 files, and does the second one include those
functions bound from the first code (EOS1) ?

Configuration
-------------

 - S-Lang has support for byte-compiled code. The module could
   save the byte-compiled code instead of (or as well as) the
   text version of the code. It may provide a slight performance
   gain when loading?
   Have decided not to try and support this, since it would mean
   more-complicated build()/load() routines for a (I'm guessing)
   effectively negligible speed increase