[Pika-dev] plans

[Tom Lord]

I've committed a revision that contains plans in 

        ./src/scm/=PLAN

A short summary is:

                   --------------------------------

Ok.  I've assembled a rough TODO list of things to do before we have
an R5RS Scheme.  I've assembled some specific notes about thosea
priority items on that TODO list that aren't "obvious".

As I mentioned earlier, I think it is practical for our initial R5RS
to have at least rudimentary Unicode support.   This is worth doing in
the initial implementation because retrofitting that functionality is
a big pain -- we already have some retrofitting to do in the lexer,
reader, and symbols and, if we don't get the Unicode basics right now,
that'll only get worse.

The TDOO list splits nicely into two parts which could be described
as:

   1) basic data structures not having to do with EVAL

   2) everything having to do with EVAL


I would like to focus the project on (1), for now.  Jivera has been
experimenting with things for (2) and I encourage that to continue --
but let's finish up the stuff in (1) before we "officially" move on to
that.

The tasks in (1) are:

~ the missing list and and vector primitives

   Andreas is working for sure on some of these, possibly on others.
   I'm sure any of us can take up any slack in this area.   This 
   stuff is pretty straightforward and presents no new issues -- just
   a handful of functions to write.



~ strings

   We're in very good shape now for rounding out hackerlab's t_udstr
   type to provide the basic functionality that we need.

   Basically, t_udstr just has to be wrapped (vtable-style) to make 
   Scheme strings but there is a catch:

   Strings present some interesting challenges for thread-safety and 
   async-code safety.   I've written a design for how to handle those
   issues (the "object-locks" file in ./src/scm/=PLAN).


~ symbols

   As strings come on line, symbols need to catch up.   Mostly, that
   just means using a t_udstr to hold a symbol's name, but there's
   a little bit more.

   The reader depends on a mapping from valid identifiers to canonical
   symbol names.   As described in "./src/scm/notes-srfi-drafts", that
   mapping is a little tricky and deserves its own procedure.

   The file "./src/scm/=PLAN/symbol-plans" describes how we can get by
   with a simple implementation of the mapping for now -- just a
   placeholder for all the unicode hair that we'll need to add.


~ ports

  I've decided to _mostly_ emulate the implementation of ports I used
  in Systas Scheme.

  In Systas Scheme, a port is just a Scheme wrapper for a raw file
  descriptor -- but the system uses hackerlab's VU so the descriptor
  can be either an system descriptor or a "virtual"
  (application-defined) descriptor.   This worked out very nicely in
  Systas.

  I want to add one new thing, though.   In Pika, a port will _also_
  have an "encoding" (e.g., iso8859-1, UTF-8, etc.)   The encoding 
  field of a port will determine the behavior of, for example,
  READ-CHAR.  

  All of this implies that the existing "cports.[ch]" code has to
  (mostly) go away and the lexer and reader have to be updated to
  handle multiple encodings.   This isn't so bad as it sounds -- the
  new code will be mostly isomorphic to the existing code, mostly
  requiring some changes to `switch' statements and the slinging
  around of some extra parameters.


Once we nail these four areas, we'll have two results:

  1) We'll have built a fairly complete C library of all Scheme types
     except for those concerned directly with evaluation --- I think
     this is independently useful from Pika Scheme.  We'll have our
     first "spin-off milestone", so to speak.

  2) They'll be nothing left to do other than to buckle down and 
     nail procedures and evaluation -- and then we'll have R5RS
     and pika-0.1




;;; arch-tag: Tom Lord Thu Mar  4 10:50:11 2004 (=PLAN/=overall)
;;;


-t