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.

PDL Support
-----------

- Conversion of S-Lang arrays to piddles fails on OS-X; need to
  investigate the assumptions in topdl.h (could be a symptom of the
  following point).

- need to test on a 64-bit machine to check that the assumptions I've made
  about sizes of the various types is sensible. Or improve the code that
  compares PDL and S-Lang datatype sizes.

- piddles <-> S-Lang arrays for > 1D: how to handle the fact that
  S-Lang 2x3 is 3x2 to PDL:

  o easy/quick
    do this conversion (just swap the dimension order during the conversion
    and leave everything else the same). Not nice if have associated data -
    eg WCS or other FITS header information.

  o keep 2x3 as 2x3
    slower/more awkward as prob would want to swap the data points
    when copying over, rather than just doing a single memcpy() call.

- Should we convert 0D piddles to S-Lang scalars or 1D, 1-element arrays?

Other data types
----------------

- 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

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

- do we need a way to say 'bind all the functions EXCEPT the following'?
  see comments in the S-Lang section of t/12arrays2slang_pdl.t

- The PDL code code be conditionally loaded by Inline::SLang - either
  via "use Inline::SLang => Config => PDL => 1;" or a separate
  "Use Inline::SLang::PDL;". Inline::Slang would have a struct (like
  PDL's Core struct) with function pointers set to NULL. When the PDL
  support is loaded these get set to the necessary code to convert
  from/to piddles.
  
  The question is, is having PDL support in Inline::SLang proper that
  much of a pain?

- 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

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.

General
-------

- *could* steal the PDL::NiceSlice ipproach 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
  So *very unlikely* to do

- improve documentation (e.g. add information to
  Inline::SLang::Details).

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

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) ?