[REBOL] Re: REBOL DOC for teaching - Some criteria I would like to share before applying
From: apwing:zonnet:nl at: 26-Jan-2004 13:23
Hi Gerard,
indeed I agree that good learning material is essential.
A short time ago I had to learn Microsoft Excel. I got hold of a few books,
but none of them really was what I liked.
So, then I came across a CD containing Excel tutorials, a lot of them being
video fragments, accompanied by somebodies voice, who told essential things
while just pointing, clicking and entering stuff on the keyboard.
Now, my experience is that you can learn a lot in a minimum amount of time
this way. It works better than executing "commands" on a one by one basis
from a book, since in the video tutorial one can see what is being done.
Currently I am experimenting with a software package (shareware) called
Hypercam ( http://www.hyperionics.com/ ). It is free to try and is very
promising!
Perhaps it is possible to write a "script" (like a film script) telling what
the tutorial should teach. Having written the script it is then easy enough
to build an AVI movie which clearly shows the steps one by one. It is even
possible to use Powerpoint to show the steps in clear text in a corner of
the screen as well.
If people in this list tend to agree with me on this, I am willing to put
some effort into it. Perhaps other (more experienced) people can write
Tutorial Scripts
and again other people (like me) then create AVI movies
from it.
Hope this may be of any help to us all.
Attached to this e-mail you will find a very easy example of what can be
done with the package.
Because of the size it is a ZIPped AVI file.
NOTE: since I am still trying out I use an unregistered version of
Hypercam!!!
Kind regards,
Arie van Wingerden
----- Original Message -----
From: "Gerard Cote" <[gerardcote--sympatico--ca]>
Cc: <[rebol-list--rebol--com]>
Sent: Sunday, January 25, 2004 7:56 PM
Subject: [REBOL] REBOL DOC for teaching - Some criteria I would like to
share before applying
> Hi List,
>
> A couple of days ago, I again revisited my 3 official books about REBOL
and each one does a great job in is own way. And I really
> think there is place for another "online" self-learning material about
REBOL - some kind of extensive tutorial . May be it will
> simply complete what is already available but I would do a bit more in the
sense of producing some teaching material for school
> usage.
>
> The main problem I encountered in the past with many teaching or
self-learning material is often related with the targeted audience
> vs the information level teachers and students were seeking for.
>
> For the moment I think there is a need for beginner's material to fulfill
and this is the direction I choos to go with.
> But when I say beginner I think to someone that is beginning to learn
computer programming and who would like to see what REBOL has
> to offer in this way. May be someone too that is not too old - from 13
years old and up seems like a great start base and I'll try
> to do my best to keep in mind many fundamental things which are
complementary to each other :
> - Material must be far from boring. Keeping it motivating is one of my
prime objectives. While some transparent interfacing is
> required to let students use View features without having to grasp its
complexity level. For example:
> if I permit the use of some LOGO like painting with View, there must be
some way to let the user's to interact with LOGO like
> commands and never see the details involved under the cover.
>
> - Examples must enforce the comprehension while kept aligned with sound
learned concepts while illustrating in parallel some well
> established design-code-debug-test methodology - nothing more but this is
no small task.
> - There is always enough place left in the personal works for
experimenting and understanding the more advanced and stimulating
> programming concepts - generally going with advanced language features and
many other external concepts to be acquired and mastered
> too don't forget about it.
>
> Finally I just reread some formal introductory material to CS which is
related to many current Programming languages including books
> about formal language independant maths and algorithms design while others
were based on a specific language like BASIC, PASCAL,
> VB, LOGO, JAVA, Lisp, SCHEME and C++.
>
> I also found many excellent tutorials about CS and programming using Java,
LOGO, Python and Scheme (Dr.Scheme).
> And today I found some text relating the interesting arguments that could
help teachers better sell REBOL as their candidate for
> teaching CS to youngsters in schools. The complete text with its reference
is enclosed in the attached segment of the original text
> that was of interest to me in this context.
>
> If you want to comment this text as a basis to establish where REBOL fails
in some way to their arguments - for getting the best
> adaptation of a teaching programming language feel free to discuss it
here.
> I'll also soon post here a first draft of my initial TOC and will require
some comments from you all to help enhance it before
> starting for the real thing. I you have any small project you would think
that could be well adapted and fun to use as code example
> in this tutorial - send it to me and I'll try to see where I can introduce
it in the pattern. Don't forget that most of the time I
> plan to use the Core so examples have to be appropriate for this kind of
UI. Later we'll try to show how adapt some functional
> scripts already using text UI to get them using a GUI instead.
>
> Some planning is required but this seems feasible too since many of the
simpler tasks involving View are also really simple to go
> with.
>
> Until then I will also work an example at a time for most current
dictionay Words to begin with. The chosen order will be based on
> my own needs for this tutorial. So it will work on both ends at a time
since I will refer to the illustrated by examples words from
> this tutorial.
>
> Many long evenings to come that are already filled in my head I think ...
>
> Regards,
> Gerard
>
> -- Attached file included as plaintext by Ecartis --
> -- File: 7-pas-vers-langage-ideal.txt
>
> Seven Deadly Sins of Introductory Programming Language Design
> Linda McIver & Damian Conway
> Department of Computer Science
> Monash University, Victoria, Australia
>
> (The original paper can be found at :
> http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf)
>
> >
>
> TOC Section 1 Seven Deadly Sins
> Section 2 Seven Steps Towards More "Teachable" Languages
>
> >
> Section 1 Seven Deadly Sins (See the original article for details
> ---------------------------- of this first section)
>
> 1. Less is more.
> 2. More is more.
> 3. Grammatical traps.
> 4. Hardware dependence.
> 5. Backwards Compatibility.
> 6. Excessive Cleverness.
> 7. Violation of Expectations.
>
> Section 2 Seven Steps Towards More "Teachable" Languages
> ---------------------------------------------------------
>
> 1. Start where the novice is.
> >
> A fundamental aspect of learning is the process of assimilating
> new concepts into an existing cognitive structure
> [19,20,21]. This process, known variously as connecting,
> accretion or subsumption, is made all the more difficult if
> parts of the existing structure have to be removed
> (unlearning) or restricted (exceptions).
>
> Hence, the novice who must unlearn that x or . means multiply,
> and then substitute * in a programming context, faces a harder learning
> task than the student who can continue to put their knowledge
> of x to use.
>
> Similarly, students have a large corpus of
> knowledge regarding integer and real arithmetic, which
> cannot be capitalised upon if they must disregard it to cope
> with finite precision representations.
>
> Another example of this type of difficulty is the use of
> = variants for assignment.
>
> Many students, when confronted with this operator, become
> confused as to the nature of assignment and its relationship
> to equality.
>
> For example, seeing the following sequence of statements :
>
> X = 3;
> Y = X;
> Y = 7;
>
> novice students sometimes expect the value of X to be equal
> to 7 (since "Y and X are equal").
>
> The equivalent sequence:
> X <- 3;
> Y = X;
> Y <- 7;
>
> seems to evoke less confusion, possibly because the syntax
> reinforces the notion of procedural transfer of value, rather
> than transitive equality of value.
>
> We have shown over one thousand novice programming
> students the C/C++ expression:
>
> "the quick brown fox" + "jumps over a lazy dog"
>
> and asked them what they believe the effect of the + sign is.
> Not one of them has ever suggested that the + sign is illegally
> attempting to add the address of the locations of the
> first characters of the two literal strings.
>
> Without exception, they believed that the + should concatenate
> the two strings.
>
> We believe that introductory languages should be designed
> so that reasonable assumptions based on prior nonprogramming-
> based knowledge remain reasonable assumptions
> in the programming domain.
>
> In other words, the constructs of a teaching language should
> not violate student expectations.
>
> Note that this principle has both syntactic and
> semantic implications in the selection and definition of operators,
> functions and inbuilt data types.
>
> 2. Differentiate semantics with syntax.
> >
> Novices experience great difficulty in building clear and
> well-defined mental models of the various components of a
> programming language.
>
> Syntactic cues can be of significant
> assistance in differentiating the semantics of different constructs.
> Constructs which may, to the accomplished programmer,
> seem naturally similar or analogous in concept, functionality,
> or implementation (for example: using the integer
> subset {0,1} as a substitute for a true boolean type, arrays
> being analogous to discrete functions of finite domain and
> range, arrays being implemented via pointers) still need to
> be clearly syntactically differentiated for the novice.
> We believe it is misguided to highlight the similarities
> between such constructs with similar (or worse, identical)
> syntaxes, because it initially blurs the crucial differences by
> which students can first discriminate between programming
> concepts, and later robs them of the opportunity to consolidate
> understanding by identifying these underlying conceptual
> connections themselves.
>
> 3. Make the syntax readable and consistent.
> >
> Novice programmers, like all novices, have a weak
> grasp of the "signal" of a new concept and are particularly
> susceptible to noise.
>
> This suggests that an introductory programming
> language should aim to boost the conceptual signal
> and reduce the syntactic noise.
>
> One obvious means of improving the S/N ratio is to choose
> a signal with which the recipient is already familiar.
>
> For example its is preferable to use :
>
> if rather than cond,
> head/tail rather than car/cdr,
> x rather than *.
>
> Another approach is to select signals which are consistent,
> distinct, and predictable.
>
> For example, delineating code blocks within constructs
> by <name>...end<name> pairs:
>
> loop
> if isValid(name)
> exit loop
> end if
> output name
> name <- getNextName()
> end loop
>
> It can be difficult to steer an appropriate path between
> the syntactic extremities of "less-is-more" and "more-ismore".
> On one hand, reducing syntactic noise might involve
> minimizing the overall syntax, for example:
>
> if x != y
> y <- x
> else
> x <- y
>
> rather than
>
> if (x <> y) {
> y:=x;
> }else{
> x:=y;
> }
>
> Alternatively, it may be better to increase the complexity
> of the syntax in order to reduce homonyms which blur
> the signal.
>
> For example, the meaning of the various components
> of the Turing expression (*7):
>
> f(C(p).A(I))(N)
>
> might be better conveyed with the syntax:
>
> f(C::p->AI)[N]
>
> The second form, whilst regrettably no more mnemonic
> than the first, does at least provide adequate visual differentiation
> between pointer dereference, array indexing, function
> call, and substring extraction.
>
> 4. Provide a small and orthogonal set of features.
> >
> Homonyms and synonyms are an acute problem in the
> design of a teaching language.
>
> We believe the best way to
> minimize these pedagogical impediments is to select a
> small set of non-overlapping language features and assign
> them distinct (and mnemonic) syntactic representations.
>
> A side effect of this recommendation is that, as the
> number of language constructs is restricted, those which are
> chosen must inevitably become more general and probably
> more powerful.
>
> In particular, we believe that it is important
> to provide basic data types at a high level of abstraction,
> with semantics which mirror as closely as possible the
> "real-world" concepts those data types represent.
>
> For example, we would suggest that an introductory language
> should not provide separate data types for a single
> character and a character string.
>
> Rather, there should be a single "variable length string" type,
> with individual characters being represented by strings
> containing a single letter.
>
> A full complement of string operators should be supplied,
> with operators for assignment, concatenation, substring extraction,
> comparison, and input/output.
>
> In addition, a set of
> suitable inbuilt functions (or predicates or methods, according
> to the language's paradigm) should be provided to implement
> other common operations for which operators may
> be inappropriate (for example: length of string, case transformations,
> substring membership, etc).
>
> As character strings
> may be strictly ordered, the string type should be a valid indexing
> type for case statements and user defined arrays.
>
> Likewise, we suggest that an introductory language need
> only provide a single numeric data type which stores rational
> numbers with arbitrary precision integer numerators and
> denominators.
>
> The restriction to rationals still allows the
> educator to discuss the general issue of representational limitations
> (such as the necessary approximation of common
> transfinite numbers such as PI and e), but eliminates several
> large classes of common student error which are caused by
> misapplication of prior mathematical understanding to fixed
> precision arithmetic.
>
> A single arbitrary precision numeric
> type has the additional benefit of eliminating many hardware
> dependence problems.
>
> Other features which might be provided include:
>
> . A single non-terminating loop construct, possibly
> modelled on the Turing or Eiffel loop statement,
> with an associated exit loop command which may
> be controlled by if statements within the loop.
>
> . A single generic list meta-type, allowing the user to
> define homogeneous or heterogeneous lists, indexed
> by any well-ordered type (numeric, boolean, string).
>
> . A single, consistent model and syntax for I/O.
>
> 5. Be especially careful with I/O.
> >
> With growing awareness of the importance of software
> usability, it is natural that students should be encouraged to
> engineer the input and output of their programs carefully.
>
> Too often, however, they are hampered by "more-is-more"
> programming language I/O mechanisms which are needlessly
> ornate or complicated.
>
> The essence of I/O is very simple: send a suitable representation
> of a value to a device.
>
> The complexity frequently
> observed in the I/O mechanisms of introductory languages
> often stems from a desire to provide too much control over
> the value conversion process.
>
> Somewhat surprisingly, the C++ language, not otherwise
> known for its friendliness towards the novice (*8), provides
> a reasonable (if over-featured) model of I/O.
>
> Turing also offers a very straightforward I/O model and syntax.
> We believe that the I/O mechanism for an introductory
> language should be defined at the same high level of abstraction
> as the other language constructs.
>
> We see the basic features of a good pedagogical I/O model as being:
>
> . a simple character stream I/O abstraction, with specific
> streams (for screen, keyboard, and files) represented
> by variables of special inbuilt types.
>
> . uniform input and output syntaxes for all data types
> (for example, infix "input" and "output" operators
> which may be applied between a stream object and a
> heterogeneous list of values and/or references)
>
> . a default idempotent9 I/O format for all data types
> (including character strings and user defined types),
> with appropriate formatting defaults for justification,
> output field width, numerical precision, etc.
>
> . a reasonable, automatically-deduced output format for
> user-defined data types (for example, output each
> globally accessible data member of a user-defined
> ADT, one value per line)
>
> . a simple and explicit syntax for specifying non-default
> output formatting (for example: a generic
> leftjustify function to convert any value to a
> left-justified character string of specified field width.)
>
> 6. Provide better error diagnosis.
> >
> There is a widely cherished belief amongst educators
> that one of the ways students learn best is by making their
> own mistakes.
>
> What is often neglected is that this mode of
> learning is only effective if a student's otherwise random
> walk through the problem space can be guided by prompt,
> accurate, and comprehensible feedback on their errors.
>
> Making and correcting an error is certainly a useful experience
> for expert and beginner alike, but the process of
> correction can be tortuous without meaningful guidance.
>
> Compiler error messages are often couched in unnecessarily
> terse and technical jargon which serves only to confuse and
> distress the student.
>
> By the time the messages have been deciphered and explained
> by a teacher or tutor, any useful feedback which may have
> been gained has been largely negated by the delay and stress involved.
>
> The type of feedback that students receive when compiling
> their programs typically runs along the lines of:
>
> - Syntax error near line 4
> - Not implemented: & of
> - No subexpression in procedure call
> - Application of non-procedure "proc"
>
> Even should they manage to compile their program, run
> time errors typically produce useful feedback like:
>
> - Segmentation violation: core dumped
> - Application "unknown" exited (error code 1)
> - <<function>>
>
> Error diagnosis is a weak point of most compiler technology,
> yet it is this compiler feature that novices spend
> most of their time interacting with.
>
> Whilst well-designed error feedback is not unknown (Turing
> is exemplary in this respect) many language implementations,
> particularly interpreters, have little or no error diagnosis.
>
> In these cases, errors are detected when the program executes
> in some unexpected way.
>
> Detecting and correcting errors in these implementations
> can be extremely difficult, particularly for a beginner,
> who may be uncertain what the expected behaviour
> of the program actually was.
>
> For an introductory language, error messages should be
> issued in plain language, not technical jargon.
>
> They should reflect the syntactic or semantic error that was
> discovered, rather than the behaviour of the parser.
>
> Error diagnosis must be highly reliable or, where this is
> infeasible, error messages must be suitably non-committal.
>
> For example, given the statement:
>
> int F(X);
>
> // WHERE X IS AN UNDECLARED TYPE
>
> a widely-used C++ compiler emits the error message:
>
> ')' expected
>
> rather than explaining that:
>
> An unknown type 'X' was used in the
> parameter list of function 'F'.
>
> In this case even a vague message like:
>
> There seems to be a problem with the
> parameter list of function 'F'.
>
> would be of more use.
>
> We suggest that a fully-specified error reporting mechanism
> should be an integral part of any introductory programming
> language definition.
>
> Such a mechanism must mandate plain language error messages
> and should ideally provide multiple levels of detail in error
> messages (possibly through a "tell-me-more" option).
>
> Common compilation errors (such as omitted end-of-statement
> markers or mismatched brackets) should be accurately diagnosed
> and clearly reported.
>
> Cases where the root cause of an error is not easily established
> should be reported as problems of uncertain origin, with one or
> more suggested causes offered in suitably non-committal language.
>
> Run-time errors should likewise be clearly and accurately
> reported, at the highest possible level of abstraction.
>
> It is sufficient for the expert to be informed that a segmentation
> fault has occurred, but the novice needs a hint as to
> whether the event was caused by an array bounds violation,
> an invalid pointer dereference, an allocation failure, or
> something else entirely.
>
> 7. Choose a suitable level of abstraction.
> >
> When first introduced to programming, students often
> have trouble finding the correct level of abstraction for
> writing algorithms.
>
> Some expect a very high level of understanding
> from the computer, to the extent of assuming that
> variable names will affect the semantics of the program (for
> example, believing that naming a function max is sufficient
> to ensure that it computes the maximum value of its arguments).
> Others attempt to code everything, including basic
> control structures, from scratch.
>
> To require algorithms to be coded in languages with extreme
> levels of abstraction (for example: high-end logic, functional
> or pure object-oriented languages, or low-level assembler)
> merely compounds the students' already abundant confusion.
>
> It is critical for an introductory language to approximate
> closely the abstraction level of the problem domain in
> which beginners typically find themselves working.
>
> Hence it is appropriate to provide language constructs suitable for
> dealing with basic numerical computing, data storage and
> retrieval, sorting and searching, etc.
>
> For most introductory courses, language features which support
> very low-level programming (for example: direct bit-manipulation of
> memory) or very high-level techniques (such as continuations)
> will merely serve to stretch the syntax and semantics
> of the language beyond the novice's grasp.
>
> Seven Criteria for Choosing an Introductory Language
> >
> Each of the preceding design principles also provides a
> criterion against which to evaluate the suitability of existing
> programming languages for introductory teaching.
>
> We would suggest that when evaluating a potential teaching
> language, in addition to addressing the usual considerations
> (such as language paradigm, compiler availability, textbook
> quality, establishment and maintenance costs, popularity,
> etc.), educators should also bear in mind the seven "sins"
> we have enumerated.
>
> The key questions are:
>
> . Is the syntax of the language excessively complex
> (and therefore lexically "noisy") or too sparse (and
> therefore insufficiently discriminating)? Are there
> syntactic homonyms, synonyms or elisions which
> may confuse the novice?
>
> . Are the control structures, operators and inbuilt functions
> of the language reasonably mnemonic? Are they
> likely to be consistent with students' previous
> (mathematical) experience? How much "unlearning"
> will they require of the novice?
>
> . Are the semantics of the language inconsistent, obscure,
> or unnecessarily complicated? Are there constructs
> whose invocation, behaviour or side-effects
> are likely to confuse a student or violate novices' reasonable
> expectations?
>
> . Are the error diagnostics clear and meaningful at a
> novice's level of understanding? Are they unambiguous,
> detailed and not overly technical? Are they accurate
> where possible and non-committal otherwise?
>
> . Are parts of the language subject to unnecessary
> hardware dependencies or implementation-related
> constraints? Will necessary restrictions be difficult to
> explain to the novice?
>
> . Is the language too big (over-featured) or too small
> (restrictive)? Is the level of abstraction of the language
> constructs appropriate for the practical components
> of the course?
>
> . Are the apparent virtues of the language equally "apparent"
> from the novice's perspective? Alternatively,
> are they a product of the educator's familiarity with
> the candidate language or with the languages which
> were the candidate's genetic and memetic influences?
>
> In the real world it is clear that the choice of any one
> language must necessarily be a compromise between economic,
> political and pedagogical factors.
>
> The relative importance of each of these considerations will
> depend on the specific aims and priorities of the institution,
> educator and course.
>
> Unfortunately, all too often pedagogical factors are
> neglected, or sacrificed to more obvious and prosaic concerns.
> We believe that this approach undermines the ultimate
> goal of successful student learning.
>
> Conclusion
> >
> We have enumerated seven ways in which introductory
> programming languages conspire to hinder the teaching of
> introductory programming and have also suggested seven
> principles of programming language design which may help
> to reduce those hindrances.
>
> We do not suggest that either list is exhaustive, nor that
> the principles we expound are definitive or universally applicable.
>
> The design of any programming language is an art, and the design
> of a language whose purpose is to teach the fundamental
> concepts of programming itself is high art indeed.
>
> Just as no battle plan survives contact with the enemy,
> no pedagogical language design (no matter how sound its
> design principles or clever their realization) can hope to
> survive contact with real students.
>
> Yet the outcomes of such encounters are the only meaningful measure
> of the success of an introductory language.
>
> This implies that the most important tool for pedagogical programming
> language design is usability testing, and that genuinely teachable
> programming languages must evolve through prototyping rather
> than springing fully-formed from the mind of the language
> designer.
>
> NOTES
> >
> 7 "Create a substring consisting of the Nth letter of the string returned
by
> the function f when passed the Ith element of the array member A of the
> object within collection C which is pointed to by p".
>
> 8 or indeed towards the expert!
>
> 9 Idempotence of I/O means that outputting the value of a variable and
> then reading that output value back into the same variable has no
discernable
> overall effect.
>
> String I/O is non-idempotent in most programming languages, because
strings
> are typically written out in their full length, but read in word-by-word
> (ie: to the first white-space character).
>
> References
> > [1] Wirth, N.
>
> and Jensen, K.
>
> Pascal User Manual and
> Report, Springer-Verlag, 1975.
> [2] Holt, R.C.
>
> and Hume, J.N.P., Introduction to
> Computer Science using the Turing Programming
> Language, Prentice-Hall,1984.
> [3] Geurts, L., Meertens, L.
>
> and Pemberton, S., ABC
> Programmer's Handbook, Prentice Hall, 1990.
> [4] Kernighan, B.
>
> and Ritchie, D., The C Programming
> Language, 2nd ed., Prentice-Hall, 1988.
> [5] Stroustrup, B., The C++ Progarmming Language,
> 2nd ed., Addison Wesley, 1991.
> [6] Barnes, J.G.P., Programming in Ada, Addison-
> Wesley, 1994.
> [7] Harbison, S., Modula 3, Prentice Hall, 1992.
> [8] Hudak, P.
>
> and Fasel, J.H., A Gentle Introduction to
> Haskell, SIGPLAN Notices, 27(5), May 1992, ACM
> [9] Springer, G.
>
> and Friedman, D.P., Scheme and the Art
> of Programming, The Massachusetts Institute of
> Technology, 1989.
> [10] Feuer, A.
>
> and Gehani, N., Comparing and Assessing
> Programming Languages: Ada, C, and Pascal,
> Prentice-Hall, 1984.
> [11] Conway, D.M., Criteria and Consideration in the
> Selection of a First Programming Language,
> Technical Report 93/192, Computer Science
> Department, Monash University.
> [12] Koelling, M., Koch, B., Rosenberg, J., Requirements
> for a First Year Object-Oriented Teaching Language,
> Techical Report 94/488, Computer Science
> Department, Sydney University.
> [13] Mody, R.P., C in Education and Software
> Engineering, SIGCSE Bulletin, 23(3), 1991.
> [14] Wilensky, R., LISPcraft, Norton, 1984.
> [15] Hofstadter, D., Godel, Escher, Bach: an Eternal
> Golden Braid, Part II, Chapter 10: "Similar Levels",
> Basic Books, 1979.
> [16] Stroustrup, B., The Design and Evolution of C++,
> Addison-Wesley, 1994.
> [17] Holt, R.C., Matthews, P.A., Rosselet, J.A., Cordy,J.R.,
> The Turing Programming Language: Design and
> Definition, Prentice Hall, 1988.
> [18] Clocksin, W.F.
>
> and Mellish, C.S, Programming in
> Prolog, Springer-Verlag, 1981.
> [19] Thorndike, E.., The Fundamentals of Learning, New
> York: Teachers College Press, 1932.
> [20] Ausubel, D., The Psychology of Meaningful Verbal
> Learning, Grune & Stratton, 1963.
> [21] Rumelhart, D.
>
> and Norman, D., Accretion, tuning and
> restructuring: Three modes of learning, In.
>
> W.
>
> Cotton,
> J.and Klatzky, R.
>
> (eds.), "Semantic Factors in
> Cognition", Erlbaum, 1978.
>
> -- Binary/unsupported file stripped by Ecartis --
> -- Type: application/pdf
> -- File: SevenDeadlySins.pdf
>
> --
> To unsubscribe from this list, just send an email to
> [rebol-request--rebol--com] with unsubscribe as the subject.
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/x-zip-compressed
-- File: rebol0008.zip
