Re: making up language features

[Thien-Thi Nguyen]

   From: Tom Lord <address@hidden>
   Date: Mon, 6 Aug 2001 17:11:31 -0700 (PDT)

   So how ought language design decisions be made for Guile?  Is it just
   ``Whatever faction gets tired first looses?''  or ``Whoever checks in
   code the fastest wins?''  How has that worked so far?

this depends on the scale of development, which has both political and
technical components.  AFAICT, guile has progressed towards wider fan-in
in the last couple years and continues that trend by encouraging would-
be developers to discuss their proposals and submit quality patches, and
encouraging current developers (w/ write privs) to spend some amount of
time in "project management" mode in addition to doing pure programming.
not all developers like the "m" word, so there are some roles that are
adopted by self-selected individuals who are suited to those activities.

wrt technical conflicts, i think it used to be "code wins".  recently,
due to more people involved, there is discussion (that sometimes dead
locks indefinitely), and a more experimental methodology (use configure
to choose among implementations, for example).  the latter is a more
mature process since it requires "independent" evaluation criteria.

           - Freeze new features and work on testing, performance,
             and robustness.  With tools to thoroughly measure the
             state of the implementation, further development will
             go more smoothly and produce more reliable results.

it's probably ok for some people to focus on this (i have personally
tried to add to the testing side of things, for example), while others
continue in other areas.  communication is key, of course.

           - Pick an application to build Emacs-style -- using the
             extension language as the primary implementation language,
             and make that application work well.

people do this w/o our supervision and sometimes under less-than-ideal
conditions, it seems.  you just can't stop those users...

           - Clean up the build/install process to eliminate automake
             and autoconf.

why?

           - Pick up some of the features that have worked well in
             Systas.

   I think the original goal of making a powerful extension language
   remains a good one.  I suspect that Guile needs some huge changes
   before that goal can be achieved, but perhaps there are some small
   clever changes that will have the same effect.  Regardless, more
   attention to testing and measurement would be a first step in the
   right direction and a benefit to either approach.

feel free to check out the cvs guile and add a "benchmark" directory
under test-suite.  for a simple example of this kind of methodology, see
ttn-pers-scheme subdir `ttn/testing/benchmarks/'...

thi