
This file contains random musings on the past, present, and future
state of Inline::SLang. Just because an item has made it here does not
mean it is going to be worked on in the near (or far) future.

Tests
-----

- check that S-Lang "opaque" variables passed through Perl and back to
  S-Lang still exist once the perl variable that referenced them
  has called it's DESTROY method.

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

  - use PDL

  - Structs: need to improve checking of valid field names in Perl
    eg in Perl can use 1x3, but this is not a valid field name in S-Lang

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

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

General
-------

 - need some way to find out the sizes of the various data types
   (particularly for when we add piddle support)

 - some code might be easier if we use dup() to copy the item
   on the S-Lang stack - so can still pop it off later

 - *could* steal the PDL::NiceSlice array and provide a syntax
   to access Perl versions of S-lang's arrays/structs - eg
     $a(0,2,1) gets translated to $a->get(0,2,3)
     $b.foo                       $$b{foo}
   BUT this is
     hard
     going to clash with PDL
     going to clash with Perl 6

 - improve documentation

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

