[[title
                      Rewriting Arch for Tla 2.0
]]

  Here are notes analyzing the possibility of simply rewriting tla
  as a way to accomplish the goals for 2.0.

* Past Experience

  Writing `tla' followed the same pattern as writing `larch':
  it is very natural to implement a core arch in steps because
  the core starts off with distinctly layered, independently
  useful components:

[[blockquote
 [[styled-lines

    /The Progression of Implementation Steps/

    - inventory
    - mkpatch/dopatch
    - in-tree patch-log access
    - archive access
    - simple revision builder
    - revlib support
    - commit and merge commands
    - then fancier builders, caching, etc.

    * user-parameter (`.arch-params') support in parallel with all of
    * the above
 ]]
]]

  It's a little bit more complicated this time because several of
  those steps involve both redesign *and* implementing backwards
  compatability.  For example, `inventory' will presumably use
  something besides `=tagging-method' in new-format trees and will
  change the rules for finding `tagline' tags.  At the same time,
  when run on an old-format tree, `inventory' should produce the
  same results as before.


* Librification from the Ground Up

 Obviously, it makes sense to plan librification from the ground-up
 during a rewrite.

 Arch, fortunately, can be implemented using only very simple data
 structures (file descriptors, strings, numbers, tables and
 associative tables of those, essentially).  */All/* functions in a
 `libarch' can be designed so that all parameters and return values
 are of those simple types.

 Sticking to simple types can both simplify much of the coding of
 arch and result in a library that is used more easily in more 
 situations.

 (Obviously), errors have to be propogated to callers rather than
 causing emergency exits --- a hackerlab-friendly approach to this
 was designed in an earlier conversation with rbcollins.

 So, overall, one of the first steps will be to specify the APIs for
 basic data types and the API conventions for `libarch' functions.

 One hard part of this step concerns Unicode:  the `string' type 
 `libarch' uses should have, at least, a Unicode-friendly API.

 One interesting opportunity during this work is to make `libarch'
 *"reflective"*: for example, to have `libarch' contain a data 
 structure which describes the argument and return types of
 every `libarch' function;  to have a way to invoke a `libarch'
 function given only a table of the arguments to it and 
 the name (a string) of the function.


* Relationship to XL

 The data structure and API conventions chosen for `libarch' are,
 in essense, the built-in data-structures and API conventions of
 the */XL runtime system/*.

 That's true, more or less, by definition.

 My reasoning, while wearing my */XL Language Designer Hat/*, is that
 XL is really aiming to be an awk-like language, but with C-like
 pragmatic prowess.  "Awk-like" in the sense that it gives a simple
 and relatively familiar programming model, perhaps with some
 idiosyncratic ways to manage flow of control, on top of a very
 minimalist set of easy-to-implement data types.   "C-like" in the
 sense that it should be a fast and functionally "complete"
 environment, practical in 90% or more of the cases where */C/* is the
 current first choice.

 */Arch/* is itself a program specification which admits a clear,
 clean, awk-ish high level expression --- but which also requires, to
 be practical, an implementation with C-like performance
 characteristics.

 Since I believe in the possibility of */XL/* --- a language that
 bridges that Awk-like or C-like gap --- a rewrite of arch is a
 good opportunity to put stakes in the ground and design a good
 chunk, at least, of the XL run-time system: a set of of core
 data structures and calling conventions.

 In other words: I'm committing (so far) to building */GNU Arch 2.0/*
 on top of the first version of the */XL Run-time System/*.

 I'm not *committing* to actually then writing any of 2.0 in */XL/*,
 although that is certainly an idea I have in mind.


* Next Steps

 On the one hand, I plan to keep making progress on the "programmer's
 blog."   That counts as prototyping higher-level UI features for 2.0,
 but it only indirectly counts as progress on the code-base for an 
 actual 2.0 implementation.   (Many of the data structures I'm working
 on for `gtla' and the blog are virtually certain to see re-use in 2.0
 but there is a certain amount of `gtla' code which, really, is only
 a discardable prototype of some 2.0 features.)

 On the other hand, I'd like to get started on the 2.0 code base
 more directly.

 I think that `inventory' probably makes a good first milestone
 to aim for:

 In order to write a brand-new, stand-alone,
 new-project-tree-format-defining implementation of `inventory' I will
 first have to spec out the details of "Librification" for 2.0.

 Having speced out those interface and run-time system requirements,
 actually implementing `inventory' will make a good test.    Does the
 proposed approach to librification actually work out smoothly in
 practice?


* Copyright

 /Copyright (C) 2004 Tom Lord/

 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2, or (at your option)
 any later version.

 This program is distributed in the hope that it will be useful,
 but /WITHOUT ANY WARRANTY/; without even the implied warranty of
 /MERCHANTABILITY/ or /FITNESS FOR A PARTICULAR PURPOSE/.  See the
 GNU General Public License for more details.

 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software Foundation,
 Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

 See the file `COPYING' for further information about
 the copyright and warranty status of this work.



[[null
   ; arch-tag: Tom Lord Wed Nov 24 10:44:39 2004 (communications/rewriting-arch.txt)
]]


 