guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JACAL, scm


From: Tom Lord
Subject: Re: JACAL, scm
Date: Fri, 21 Sep 2001 12:54:45 -0700 (PDT)


       Therefore we are currently more concerned with improving
       maintainability and facilitating the use of Guile as an
       embedded language in applications than optimizing the current
       evaluator.

On the subject of maintainability and embedding, Systas can offer some
nice contributions there, as well, though the process by which those
contributions could become part of Guile will require careful
consideration.

Here is some of what's there:


1) A system for cleanly encorporating documentation into source
   code, as C comments, is in place.  It could use more features,
   and the implementation needs to be tightened up, but it
   works quite well.

   The advantages of my documentation systems include:

        - Very little "ugly" markup is needed.  Instead,
          the structure of documentation comments is mostly
          extracted from conventions using punctuation and
          indenting.  The comments read very easily all 
          by themselves, without lots of "@foo{bar}" 
          or "<mumble>spaz</mumble>" getting in the way.

        - The comments are not particular to any given 
          formatting system.  The doc-extractor currently
          generates both HTML and texinfo from the same source.
          The HTML generated is superior to what can be 
          done with info->html converters.

2) The header files have been extensively overhauled and regularized.
   Header file function declarations are maintained by an automated 
   tool.  Many (though not quite all) horrible macros have been
   cleaned up.

3) Naming conventions have been substantially improved in the
   direction of eliminating StudlyCaps and other hard-to-type
   names.  I have a file of about 150 dynamic abbrev definitions
   that makes typing new code a lot easier.

4) Function prototypes in function definitions are formatted in
   ordinary C, rather than using a macro.  Macros are needed to
   declare Scheme built-in procedures, but those macros are
   mostly maintained by a semi-automated tool

5) A system of clever Makefiles and conventions is in place for
   maintaining test cases for both C and Scheme code.  This makes
   it convenient to run tests every time you modify the interpreter.

6) The code has been made sufficiently portable that autoconf is 
   no longer needed for the core interpreter.  The code has not
   recently been ported beyond FreeBSD, but it has been so ported
   in the past, and could easily be refreshed in this regard.

7) The tag system has been overhauled with the goals of good
   performance, simplification and freeing up tag space for new
   types.

8) The bootstrapping Scheme code has been generally cleaned up,
   as has the larger library of Scheme modules.

9) Handling of Unix signals and other asynchronous events has been
   re-done for robustness and clarity.

10) The unix system call interface has been completely overhauled,
    aiming for (near) completeness, regularity, flexibility, and
    simplicity.

Probably there are other maintainability-improving changes that
I've forgotten about.

Regards,
-t



reply via email to

[Prev in Thread] Current Thread [Next in Thread]