This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Testcases for append! in greg style.



Have you looked at test-suite/lib.scm?  It's pretty heavily commented.

(test-suite lib) has the following features, that I don't *think* greg
has:

- the ability to mark independent groups of tests, so that if one
  test hits an error, we don't just abandon the whole file

- the ability to group a bunch of tests and specify a common prefix
  to use in their names.  Every test needs to have a distinct name, or
  else you can't figure out what code failed; this is a natural and 
  convenient way to help do that.

- the ability to test whether a piece of code signals an error, not
  simply whether some expression is true or false

- a layer between the tests themselves and the code that prints out
  the results ("reporters"), so you could catalog them or record them
  in other ways.  For example, the code at the bottom which prints out
  the total number of passes, fails, etc. isn't a special case wired
  into the PASS and FAIL primitives --- it's just another consumer of
  the data stream that those primitives create.  You can write your
  own.  (test-suite lib) currently provides:

  - "count" reporters, which record total passes, total fails, etc.
  - "log" reporters, which store results in a file in a
    machine-readable syntax
  - "user" reporters, which print results in a human-readable form.

- a reasonable-sized body of Guile tests written in it already.



> > >    The solution was to store _every_ object of x in a separate structure
> > >    before the operation is applied.  Thus, each cell as well as its
> > >    contents are stored.  After the operation is performed, compare the new
> > >    value of x with the set of its original elements.
> > 
> > Ahh, how I love lisp.
> 
> Probably I reinvented the wheel? :-)  Maybe I sounded too enthusiastic
> about what I did:  I just wanted to provide some explanation for the
> code, which otherwise might seem quite strange.
> 
> Maybe that's something that a scheme programmer should not say if he does
> not want to make a fool of himself, but I say it:  I don't know
> lisp.  Okay, I do know elisp (and like it, but not as much as scheme), but
> I still don't get what you mean with your reference to lisp.


No, I thought your idea was very clever.  But notice that it's
impossible (or at least annoying) to write generic routines like yours
to record a structure in languages like Java or C++, because the
precedent there is that you must make up your own types for
everything.  But if you create your own types, you have to write all
your own operations on those types.  In the Lisp family of languages,
of which Scheme is a member, there's a precedent for using the
existing types when possible, which facilitates cool tricks like
yours.

If you know Scheme or Common Lisp, I think you know the essence of
lisp.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]