1
Fork 0
mirror of https://git.savannah.gnu.org/git/guile.git synced 2025-06-29 22:40:34 +02:00
guile/test-suite
Andy Wingo 8a4ca0ea3b tree-il support for case-lambda
* module/language/tree-il.scm (<lambda>, <lambda-case>): Split lambda
  into the lambda itself, denoting the procedure, and lambda-case,
  denoting a particular arity case. Lambda-case is fairly featureful,
  and has not yet been fully tested.
  (<let-values>): Use a <lambda-case> as the binding expression. Seems
  to suit the purpose well.
  Adapt parsers, unparsers, traversal operators, etc. Sometimes in this
  first version we assume there are no optional args, rest args, or a
  predicate.

* module/language/tree-il/analyze.scm (analyze-lexicals): Adapt for the
  new case-lambda regime. Fairly well commented. It actually simplifies
  things.
  (report-unused-variables): Update for new tree-il.

* module/language/tree-il/compile-glil.scm: Adapt for the new tree-il.
  There are some first stabs here at proper case-lambda compilation, but
  they are untested as of yet.

* module/language/tree-il/inline.scm (inline!): Rework so we can
  recurse on a single node; though these transformations are strictly
  reductive, so they should complete in bounded time. Simplify
  accordingly, and adapt to case-lambda. Oh, and we handle lambda->let
  in not just the nullary case.

* module/ice-9/psyntax.scm (build-simple-lambda, build-case-lambda)
  (build-lambda-case): New constructors. The idea is that after syntax
  expansion, we shouldn't have to deal with improper lists any more.
  Build-simple-lambda is a shortcut for the common case. The others are
  not fully exercised yet. Adapt callers.
  (syntax): Add some debugging in the lambda case. I don't fully
  understand this, but in practice we don't seem to see rest args here.
  (lambda): Inline chi-lambda-clause, and adapt for build-simple-lambda.
* module/ice-9/psyntax-pp.scm: Regenerated.

* test-suite/tests/tree-il.test: Update tests for new tree-il lambda
  format, and to expect post-prelude labels for all glil programs.
2009-10-23 15:10:25 +02:00
..
standalone Revert "Change dynwind flag enums to #defines, for greater portability" 2009-10-07 22:14:38 +01:00
tests tree-il support for case-lambda 2009-10-23 15:10:25 +02:00
ChangeLog-2008 Rename ChangeLog' files to ChangeLog-2008'. 2008-09-12 21:49:58 +02:00
guile-test Change Guile license to LGPLv3+ 2009-06-17 00:22:09 +01:00
lib.scm Don't presume existence or success of setlocale in test-suite 2009-08-28 06:27:00 -07:00
Makefile.am Avoid throw from critical section, given invalid sigaction call 2009-09-30 21:39:01 +01:00
README Revert "Note need for subscription to bug-guile@gnu.org." 2008-12-10 19:07:14 +00:00

This directory contains some tests for Guile, and some generic test
support code.

To run these tests, you will need a version of Guile more recent than
15 Feb 1999 --- the tests use the (ice-9 and-let*) and (ice-9
getopt-long) modules, which were added to Guile around then.

For information about how to run the test suite, read the usage
instructions in the comments at the top of the guile-test script.

You can reference the file `lib.scm' from your own code as the module
(test-suite lib); it also has comments at the top and before each
function explaining what's going on.

Please write more Guile tests, and send them to bug-guile@gnu.org.
We'll merge them into the distribution.  All test suites must be
licensed for our use under the GPL, but I don't think I'm going to
collect assignment papers for them.



Some test suite philosophy:

GDB has an extensive test suite --- around 6300 tests.  Every time the
test suite catches a bug, it's great.

GDB is so complicated that folks are often unable to get a solid
understanding of the code before making a change --- we just don't
have time.  You'll see people say things like, "Here's a fix for X; it
doesn't cause any regressions."  The subtext is, I made a change that
looks reasonable, and the test suite didn't complain, so it must be
okay.

I think this is terrible, because it suggests that the writer is using
the test suite as a substitute for having a rock-solid explanation of
why their changes are correct.  The problem is that any test suite is
woefully incomplete.  Diligent reasoning about code can catch corner
conditions or limitations that no test suite will ever find.



Jim's rule for test suites:

Every test suite failure should be a complete, mysterious surprise,
never a possibility you were prepared for.  Any other attitude
indicates that you're using the test suite as a crutch, which you need
only because your understanding is weak.