(no subject)
Marcel K Haesok
kind o cozy, this newsgroup, not too many people, it feels good that
way, especially since lisp seems to
be the derigeur elite language. As a rookie, I am overly excited to
learn lisp. Would someone please offer a
few words of guidance? (I am familiar with OO---bit of Java, C++ and my
bread and butter powerbuilder)
Ps: somewhere above, someone mentioned that lisp ought to serve much
more than just for AI. That may be true.
But I feel that AI will be where the action is in the very near future.
Mainly because "memory" is escalating
in its capacity and speed in an astronomical rate. (Incidentally, could
someone tell me how many giga bytes
our human brain is? ) As one who both loves James Joyce and computing,
what I would love to see would be a
"James-Joyce-talk-alike" or a "Virginia Woolf Talk-alike" cyber being
talking to me over the internet. And I
feel that with the help of Lisp and huge memories, it will not be too
far off. Am I rambling? Marcel
Marcel K Haesok
be very difficult. I will begin the journey nonetheless. One thing one can say
about programming is that it is the opposite of 'dead-end' job. It is 'no-end'
job. You just let the years slide by while you just do rote work and you get
paid more and more. So the journey is worth it. Thanks again. Marcel.
Sunil Mishra wrote:
> Marcel K Haesok <Hae...@earthlink.net> writes:
>
> > Hi all,
>
> > kind o cozy, this newsgroup, not too many people, it feels good that way,
> > especially since lisp seems to be the derigeur elite language. As a
> > rookie, I am overly excited to learn lisp. Would someone please offer a
>
> Don't be overly excited, very will do fine for this newsgroup :-)
>
> > few words of guidance? (I am familiar with OO---bit of Java, C++ and my
> > bread and butter powerbuilder)
>
> Hmmm... Patience, perhaps? Learn what the language is good for, and try to
> not look for direct equivalents between C++ and Lisp.
>
> Pick up a good book for learning. Here they use Paul Graham's ANSI common
> lisp.
>
> Finally, visit http://www.elwoodcorp.com/alu/
>
> > Ps: somewhere above, someone mentioned that lisp ought to serve much more
> > than just for AI. That may be true. But I feel that AI will be where the
> > action is in the very near future. Mainly because "memory" is escalating
>
> Debatable. Also depends on what definition of AI you apply. But let's not
> get into this here, this is a far more appropriate topic for comp.ai.
>
> Sunil
Sunil Mishra
Thomas A. Russ
Marcel K Haesok <Hae...@earthlink.net> writes:
> ....As a
> rookie, I am overly excited to learn lisp. Would someone please offer a
> few words of guidance? (I am familiar with OO---bit of Java, C++ and my
> bread and butter powerbuilder)
Two concepts that are different in Lisp than in other languages:
(1) All forms in Lisp return a value. That means that the language
doesn't draw a distinction between expressions and statements.
Effectively it means that all forms are expressions.
This simple difference actually has a profound effect on the style
of programming, since it means that there is a lot more nested
structure to Lisp programs and fewer variables.
One other consequence is that Lisp on needs a single conditional
form IF rather than having both statement "if ... then ... else"
and expression "... ? ... : ..." forms.
(2) The object model in CLOS is very much different from many other OO
languages. In CLOS, objects encapsulate data only, not data and
behavior.
Generic functions are used to organize behavior. Methods do not
belong to classes, but rather to generic functions.
What this means is that all methods with the same name should do
roughly the same operation, but on arguments of different types.
It would be bad style to have radically different methods share
the same name (and coincidentally the same argument list).
Finally, I would suggest that you read your book next to the computer,
so you can try things out as you go along. The interpreter in Lisp
systems makes this very easy and should speed up the learning process.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Tim Bradshaw
> (1) All forms in Lisp return a value. That means that the language
> doesn't draw a distinction between expressions and statements.
> Effectively it means that all forms are expressions.
>
> This simple difference actually has a profound effect on the style
> of programming, since it means that there is a lot more nested
> structure to Lisp programs and fewer variables.
It also is fundamental to the extensibility of the language. Writing
Lisp code which manipulates `higher-level' -- really `more human' --
code and produces `lower-level' -- really `more computer' code is made
extremely easy by the fact that, in Lisp, what would be a block in C
(say) is an expression, which returns a value. For instance, in Lisp
I can say:
(setf x (with-open-file (in "myfile" ...)
(read in)))
where WITH-OPEN-FILE is something that expands to a `block' which
establishes a local variable IN, which in CL might be (this is
oversimplified):
(setf x (let ((in (open "myfile" ...)))
(prog1 (read in)
(close in))))
Whereas in C I would find this extraordinarily hard:
x = WITH_OPEN_FILE(in, ..., read_file(in));
translates as:
x = { FILE *in = fopen(...);
read_file(in);
};
But this is not legal, because blocks are not expressions in C, and it
*cannot be made legal* without converting it to something where the
`in' variable is pushed up to a higher scope, so you lose.
The ability to have code which reasons about code -- `macros' in
Lisp-speak -- is one of the defining charactersitics of Lisp, and, for
me, makes Lisp-family languages an extraordinarily good environment
for thinking about computational problems.
> (2) The object model in CLOS is very much different from many other OO
> languages. In CLOS, objects encapsulate data only, not data and
> behavior.
>
> Generic functions are used to organize behavior. Methods do not
> belong to classes, but rather to generic functions.
>
It's worthwhile saying why this is so (or one of the reasons it is
so). CLOS has multiple-dispatch -- a method can depend on the classes
of more than one of its arguments. A good example of where this is
useful is something like a display method:
(DISPLAY thing medium)
needs to depend both on the sort of thing (a postscript drawing or
something), and the medium (paper, screen).
But multiple-dispatch makes it very hard to see behaviour as
`attached' to an object, or to regard methods as responses to
`messages' sent to objects. So CLOS doesn't do that. Some previous
Lisp Object systems (old flavors) did.
One of the problems with CLOS is that many of the cultures that have
grown up around OO programming are based in a less rich model (single
dispatch, often single-inheritance, and simpler in other ways too),
and then *fail to distinguish* between tricks required because their
model is too poor, and fundamental issues. A good example of this are
some design patterns (not all), which are really irrelevant in CLOS.
--tim
Erik Naggum
| (1) All forms in Lisp return a value.
even (VALUES)? sorry, I had to.
#:Erik
Christopher R. Barry
Is this the only ANSI Common Lisp form that does not return a value?
(Plenty of stuff in other packages do things only by side-effect with
no return values - like evaluating (GC) under Allegro CL, for
example.)
Christopher
Kent M Pitman
> * t...@sevak.isi.edu (Thomas A. Russ)
> | (1) All forms in Lisp return a value.
>
> even (VALUES)? sorry, I had to.
What he meant to say was that "all forms in Lisp return values".
(As if the novice reader would hear that any differently...)
Kent M Pitman
> Erik Naggum <er...@naggum.no> writes:
>
> > * t...@sevak.isi.edu (Thomas A. Russ)
> > | (1) All forms in Lisp return a value.
> >
> > even (VALUES)? sorry, I had to.
>
> Is this the only ANSI Common Lisp form that does not return a value?
> (Plenty of stuff in other packages do things only by side-effect with
> no return values - like evaluating (GC) under Allegro CL, for
> example.)
(defun foo () (values))
(foo) => no values
Incidentally, the function PPRINT returns no values.
Howard R. Stearns
>
> * t...@sevak.isi.edu (Thomas A. Russ)
> | (1) All forms in Lisp return a value.
>
> even (VALUES)? sorry, I had to.
>
I think our terminology is no quite rich enough.
The original context was refering to the use of a "result" in some
context.
Every Lisp expression returns a result that can be used, and the rules
are always the same:
If the thing which receives the result is not doing anything with it,
the result
is ignored.
If the thing which receives the result is passing the result on, then
it is
passed on without further manipulation.
If the thing which receives the result is doing a variable or
parameter
assignment, then the first value is used. If there are no values,
the
"result" used instead is NIL.
If the thing which receives the result is manipulating multiple values
somehown,
then it does what it does.
Thus, "All forms in Lisp return a result."
Christopher R. Barry
> cba...@2xtreme.net (Christopher R. Barry) writes:
>
> > Erik Naggum <er...@naggum.no> writes:
> >
> > > * t...@sevak.isi.edu (Thomas A. Russ)
> > > | (1) All forms in Lisp return a value.
> > >
> > > even (VALUES)? sorry, I had to.
> >
> > Is this the only ANSI Common Lisp form that does not return a value?
^^^^
Whoops.
> (defun foo () (values))
>
> (foo) => no values
The Lawyer nailed me.
> Incidentally, the function PPRINT returns no values.
What I had in mind. Thanks.
Christopher
Thomas A. Russ
Erik Naggum <er...@naggum.no> writes:
> * t...@sevak.isi.edu (Thomas A. Russ)
> | (1) All forms in Lisp return a value.
>
> even (VALUES)? sorry, I had to.
I'll refrain from pointing out that I was trying to come up with a very
high-level overview for a language new-comer, rather than a detailed
technical spec.
But in the spirit of bit twiddling, I will claim that the (VALUES) form
must in some sense have a value if needed by the caller, since otherwise
it should be an error to write:
(if (values) 'true 'false)
and the result of
(list (values) 1 (values) 2)
should not be
(NIL 1 NIL 2)
Erik Naggum
| high-level overview for a language new-comer, rather than a detailed
| technical spec.
well, I think high-level overviews that contradict detailed technical
specs are destructive and that if we cannot express ourselves save by
contradicting the specifics, we do not have a consistent language to
begin with, and high-level overviews should not be attempted. the task
must be to find the appropriate way to express language characteristics
that hold true no matter how deep we dig into the specifics.
a new-comer needs to understand that there is no syntactic concept of a
"statement" in the Algol sense in Lisp. while it is true that Lisp forms
return values, I think the important difference between Algol and Lisp in
this regard is that there is no restriction on where a form can be used,
syntactically. (there are a number of semantic restrictions, of course.)
this lack of restriction leads to the _conclusion_ that Lisp has been
designed with a concern that forms should return useful values, even if
they are intended for side effects, and that not using such values is not
an error -- the form will still be fully evaluated.
the important distinction is between languages that drive an artificial
wedge between "statements" and "expressions" and languages that do not:
the Algol family (including Scheme) does feature this artificial wedge,
while the Lisp family (excluding Scheme) does not.
#:Erik
Marcel K Haesok
I just returned after two days and was happily surprised to see this thread stretched quite a bit. I am getting a really good introduction to Lisp by reading all the discussion. Thomas Russ' statement that 'all lisp forms return a value', I must say, gave me a sort of shocking preview into Lisp, and in that gave me a very good insight. And these dicussions are really super-duper. I ought to thank you all but I know you all are enjoying yourselves too, so, but anyways, I thank you all. Marcel.
Rob Warnock
+---------------
| the important distinction is between languages that drive an artificial
| wedge between "statements" and "expressions" and languages that do not:
| the Algol family (including Scheme) does feature this artificial wedge,
| while the Lisp family (excluding Scheme) does not.
1. Remember that BLISS, definitely a member of the Algol family (IMHO),
was also quite explicitly an "expression language". Every control form
in BLISS (including loops) could deliver a value that could be used
in any value-requiring place -- *including* the "left-hand side" of
an assignment operator (which requires a pointer object value).
Example legal (to the extent that I remember it correctly) BLISS:
// for brevity, assume w.l.g. that a match will always be found
search: begin
local table_structure p = table_head;
while .p[NEXT] neq EOL_MARKER
do if some_predicate(.p[ELEMENT])
then leave search with p
else p = .p[NEXT]
fi
elihw
end [ELEMENT] = .foo; // foo contains new value for the table
(By the way, the value of a BLISS loop that terminates "normally"
[without a "return" or "exit" or "leave"] was explicitly defined to
be "-1". Often not terribly useful, but *defined*, so you could
depend on it for a post-loop test.)
2. I strongly disagree with your assessment of Scheme in this respect.
To me, it quite clearly falls on the "everything has a value" side
of the line, at least as much as CL. True, for some forms the standard
says the values are "not specified" (e.g., "set!"), but *some* value
is required to be delivered. E.g., the following is quite legal Scheme:
> (define foo 1)
> (define bar 2)
> (set! foo (set! bar 3))
Now, exactly *what* the value of "foo" is at this point is quite
implementation-dependent (as it is allowed to be by R5RS), but it
definitely *has* a value. [In Elk, it's "2", the previous value of
"bar"; in MzScheme, it's the "#<void>" object; in SCM, it's the
"#<unspecified>" object (hah! talk about an oxymoron!).]
I'd be interested to hear what in Scheme causes you to toss it
so cavalierly into the non-expression-language camp.
-Rob
-----
Rob Warnock, 8L-855 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
Erik Naggum
| I'd be interested to hear what in Scheme causes you to toss it so
| cavalierly into the non-expression-language camp.
the stuff you just mentioned about the value of side-effecting forms, and
SET!, in particular. saying that it returns a value is like saying that
an unbound slot in a class instance has a value. clearly, these forms
are not intended to be used for their value, and the language is quite
explicit in that respect. had the language defined SET! to return the
new value of the object that got it, and DEFINE to return either the
symbol or the object, I would have had a much weaker case. as it stands,
however, Scheme does proper homage to the Algol tradition, to which it
was dedicated, at least as of R4Rs. (I personally think it's a serious
mistake to try to marry Algol to Lisp, and Scheme is the bastard that
came out of it, but this is not something I thought before I studied
Scheme, it's a conclusion after watching the horrible messes people who
like Scheme willingly get themselves into.)
BTW, if Scheme had had a _value_ that could be compared with the result
of SET!, things would also look very different.
#:Erik
Kent M Pitman
> well, I think high-level overviews that contradict detailed technical
> specs are destructive and that if we cannot express ourselves save by
> contradicting the specifics, we do not have a consistent language to
> begin with,
This is a theory of teaching, and not without merit, but it is not
unique among teaching theories.
In my education, I was routinely taught lies or simplifications
(depending on how charitable you are toward the teacher). When I
learned math as a child in school, I was taught a number was
1,2,3,...,9. Later I was taught about 2-digit numbers. Later I was
taught about 0. And later about negative numbers. Always these were
"whole world" views, but they omitted stuff. At some point I even
asked if the set they were teaching was complete, and probably someone
told me it was or that there was "only this one more thing". Like
reals in place of rationals (failing to mention complexes), and so on.
Would I have learned math better if someone had started with a full
theory of complexes, or with the right terms but just lots of missing
elements conspicuously waiting for years to be filled in? Maybe.
Maybe not. Were my teachers incompetent or liars for deciding to omit
information? I don't really think so. Most of my classmates, I'm
pretty sure, would have done even worth with a tell-all approach,
honest though it might have been.
I think it's great to create a theory of teaching that is monotonic and
to push it as far as you can with whomever you can get it to resonate
with. But I'm quite sure from my experience with students that it is
not for everyone, and so I repeat myself for the n-thousandth time in
saying that there is no "good" or "bad" absent a context. Teaching
is always done in a context, and often in a context particular to the
student or the instructor's estimation of a student. Probably it would
be good if we all knew when someone asked a question whether they were
of the Erik school or the Russ school ... but often we don't know.
So we make guesses about what people will like, and as often as not we're
wrong.
It's probably why half the time people say you, Erik, are a very
interesting guy to listen to and the other half of the time people get
all up in arms about how the perceive some problem with you. It's not
as simple as either group just being just right or just wrong--we're a
pluralistic group with different preferences not only technically but
in how we receive technical information. When that aligns, we are happy;
when it doesn't, we are sad. Or so, at least, I perceive... FWIW.
I hope this set of observations on my part doesn't start any big
debate, since it was mostly meant to keep one from starting. Just
being a bit philosophical tonight in between rebuilding linux kernels
over and over without success (and wishing I was dealing with network
card vendors that didn't think "i'm trying to get this to work under
linux" was geekspeak for "i don't require the same kind of commercial
quality support you'd give me if i was using any other operating
system").
Kent M Pitman
> > (define foo 1)
> > (define bar 2)
> > (set! foo (set! bar 3))
>
> Now, exactly *what* the value of "foo" is at this point is quite
> implementation-dependent (as it is allowed to be by R5RS), but it
> definitely *has* a value.
The simpler example would have been
(length (list (set! x 1)))
since this uses the result for its objectness but not for any other
aspect of itself.
Rob Warnock
+---------------
| The simpler example would have been
| (length (list (set! x 1)))
| since this uses the result for its objectness but not for any other
| aspect of itself.
That's easy, (length (list (set! x 1))) ==> 1
And (list (set! x 1) (set! x 2)) ==> (#<void> #<void>)
Rob Warnock
| SET!, in particular. saying that it returns a value is like saying that
| an unbound slot in a class instance has a value. clearly, these forms
Minor quibble: The value in (most) Scheme(s) of set!/define/(if #f #f) is
*not* the same as an "unbound slot", or at least, *not* the same as an
unbound variable in Scheme. The "unspecified value" is (must be?) a real
first-class value that can be stored in an object, passed as a parameter,
tested against, and (very unlike an "unbound variable") does *not* cause
a error when referenced. [Whether that behavior is *useful* or not is a
different issue.] It's just that the type and semantics of that value
aren't defined by the standard, nor is every legal "statement-like" form
or sub-form required to produce the *same* value (that why it's called
"unspecified"). Some implementations do; some don't.
+---------------
| BTW, if Scheme had had a _value_ that could be compared with the result
| of SET!, things would also look very different.
+---------------
As I said, most implementations do have such a value[*], but it's not
usefully standard or portable [although I have occasionally used it to
pretty-up my own specialized REPLs, usually just to suppress the printing
of that value], so your point is well taken.
+---------------
| had the language defined ... DEFINE to return either the symbol or the
| object, I would have had a much weaker case.
+---------------
Actually, for DEFINE your case for "statement"-ness is extremely *strong*,
since according to my reading of the standard, there's no syntactic way
to place a top-level Scheme "define" in a place where its value (if it
had one) could be captured without turning it into an "internal define",
which is syntactic sugar for a completely different construct (a "letrec").
[That said, all of MzScheme/SCM/Elk *do* allow (define foo (define bar 1)),
which actually seems a bit weird even to me!]
-Rob
[*] Most readers will probably want to ignore this...
For MzScheme, the built-in procedures "void" and "void?" give you
access to the "magic value" returned by "define", "set!", "display",
and the one-legged "if", that is, (if #f #f), and so on:
(void) ==> #<void>
(void? (void)) ==> #t
(eq? (void) (set! foo 'whatever)) ==> #t
(void? (if #f #f)) ==> #t
and:
(define foo (define bar 1))
bar ==> 1
foo ==> #<void>
but: (void? (define foo (define bar 1))) ==>
define-values: illegal use (not at top-level)
in: (#%define-values (foo) (define bar 1))
For SCM, the following definitions can be used to get similar behavior
(it prints as "#<unspecified>" instead of "#<void>"):
(define (void) (if #f #f))
(define (void? x) (eq? x (void)))
but this works:
(void? (define foo (define bar 1))) ==> #t
bar ==> 1
foo ==> #<unspecified>
For Elk, the value of "set!" is the previous value of the variable being
set, but even though that's "well-defined" (for Elk), it's *not* a constant
(it sounded like that might matter to you). Worse, the other usual suspects
all return *different* magic values:
(display 'whatever) ==> [the symbol (string->symbol "")]
(void? (string->symbol "")) ==> #t
(if #f #f) ==> () ; so (void? (if #f #f)) ==> #f
Jussi Piitulainen
> the important distinction is between languages that drive an
> artificial wedge between "statements" and "expressions" and
> languages that do not: the Algol family (including Scheme) does
> feature this artificial wedge, while the Lisp family (excluding
> Scheme) does not.
Scheme is not quite that different from the Lisp family here. Every
expression in Scheme returns values just as in Common Lisp. If the
number of values is not one, the expression must be in a certain
context. A single value is ignored in a statement position just as in
Common Lisp. Assignments and other statements can be used in argument
position just as in Common Lisp.
You are accurate about the cultural difference: assignment values are
not useful in Scheme, as Scheme does not specify what they are. This
has never hampered my style, and it does not prevent me from using
procedures that both pop a stack by side effect and return a value, or
from appending lists by side effect, if I want to, or from tabulating
computed values of a procedure transparently, or so on.
--
Jussi
Erik Naggum
| Would I have learned math better if someone had started with a full
| theory of complexes, or with the right terms but just lots of missing
| elements conspicuously waiting for years to be filled in?
Kent, I think you're overreacting. my issue is only with having a
one-shot high-level overview of something finite and fully knowable that
is _contradicted_ by fact, not about how successive approximations to a
complete understanding of something would work, especially not as used in
a situation where the teacher can control the real or apparent confusions
when moving from one approximation to the next.
I'm concerned that you appear to think that explaining a simple principle
in the design of Common Lisp (no statement/expression dichotomy) cannot
be done simply _and_ correctly, however. yet I'm not sure that's really
what you wanted to say.
when I study something, I want to know what motivated those who figured
it out, not only whatever somebody thinks would motivate me to use it.
if I understand the former, I can perhaps find a better way, combining
what I know from other motivations, and do something fun and cool. if I
only learn the latter, the best I can hope for is using existing tools,
and how fun is that?
#:Erik
Kent M Pitman
> I'm concerned that you appear to think that explaining a simple principle
> in the design of Common Lisp (no statement/expression dichotomy) cannot
> be done simply _and_ correctly, however. yet I'm not sure that's really
> what you wanted to say.
It's an issue of presentation order. I've been wrestling with this for my
book. The issue of "connecting expressions" comes up much earlier than
one wants. There's a sense of what I think of as "distraction" that comes
up from not saying something in the expected way, and one has to do one
of several things:
(1) Use an ambiguous expression and hope the person doesn't know
you're being vague until you have a chance to explain. (This is
what I'm trying to do, btw.)
(2) Use a truthful expression that forces you to indulge a presentation
order that might not be of your choosing.
(3) Lie, and fix the lie later. (A modified version of this is to "color"
the lie in a way that explains you are doing it, and then repair the
lie later; I've experimented with this "explicit lying", too.)
It is frustrating how dependent teaching is on "order" because it seems
like it should be enough to concentrate on a compositional set of concepts.
It's hard enough to get a good set of concepts, which I think is why you're
frustrated--if you are not minding the order, and willing to hold it all
in your head until the "why" makes sense, then any additional info just
makes it more painful. This is why a programming language that has explicit
"forward referencing" notations is more painful than one that does not.
We'd like to believe that the compiler would just wait and figure things
out at the right time, but presentation order affects the amount of
intermediate storage required. If you're willing to allocate more
intermediate storage, you can do a more intelligent/brief presentation.
I hate to keep referring to personality but I do believe that
personality is often a hint of something computational, just as a
program can often be debugged by its output, and I have to believe
that your personality (both your temper and your apparent quick mastry
of large issues like SGML and CL) suggest that you are either willing
or able to hold more in your head at once than some other people are.
This, I think, explains (at least partially) your difference in taste
for presentation order/style.
> when I study something, I want to know what motivated those who figured
> it out, not only whatever somebody thinks would motivate me to use it.
I think this, too, btw. But I have learned that this is not universal
and while I try to seek out places that will do this for me, I no
longer find myself surprised when it's not offered. One of the great
fallacies that I think the Lisp community got into a long time ago
which has held them back is the belief that the world is filled with
programmers that don't want to be told what to do. Perhaps the problem
is that we haven't yet developed an etiquette about asking the right set
of parametric questions in advance of teaching to determine which
style is right. Perhaps because you (and sometimes I) have not been
through the point of courtesy in a teaching dialog where the teacher asks
"I am at a choice point in presentation. Are you most comfortable receiving
information in mode X (assumes attention span and initiative by you)
or mode Y (assumes boredom and need to be motivated)?" you assume that
this decision has not been made. Often, in my teaching, I skip this step,
mostly because just as it's hard for the student to adapt, one's teaching
style can be equally hard to adapt. I allege it's more important to have
agreement on the teaching style than to choose one or the other, and having
so alleged, I claim that your ire above can be re-characterized properly
by me saying that you're detecting a teaching-mismatch between you and
the teacher--but since you weren't the student, the mismatch may or may
not have been ill-identified. To the extent that the student is "like you",
which is certainly possible, then you're right to be alarmed because there
is a more efficient mode of presentation. To the extent that the
student is "of the other kind" (or "kinds"), then alarm may or may not
be appropriate.
I'm only trying to open conversational space enough to admit that you
are not necessarily right, but I'm not saying you are definitely wrong
in this case. I really do think there are two points of view active
here, and that you are correctly identifying an issue that might have
been neglected, but I also think your statement of that fact doesn't
necessarily (within context of the particular student) mean that a bad
choice was made--only that a bad choice might have been made.
I've actually appreciated the opportunity to think through the issues
in this explicit way because it gives me some concrete food for
thought in how to present my book and to better inform the reader to
take the information more smoothly.
> if I understand the former, I can perhaps find a better way, combining
> what I know from other motivations, and do something fun and cool. if I
> only learn the latter, the best I can hope for is using existing tools,
> and how fun is that?
I'll compare this to a game of solitaire in which the deck is stacked
against you and you can't win .. or to the recent query from someone
about whether you can "efficiently" sort a linked list. The issue
isn't getting a maximal score, it's getting a maximal score within
context. It might be that some people are poised to lose from the
outset unless you do things in a certain way for them that lets them
achieve a less good score. If you proceed from the assumption that
you must maximize the rare case of having everything in your favor,
you may suffer a hill-climbing problem where you max out and cannot
repair the damage with the remaining available resources. e.g., in the
solitaire game, it's not fair to put the cards back on the deck and try
a different strategy. To some extent, an extremely careful teaching order
can get you headway without sacrificing anyone's total score. And to
some degree, I think you have to say that those who don't self-identify
as wanting the information in a certain special form must take it in
the order that maximizes the "average best score" not the "best best score".
To some extent, perhaps Lisp is guilty of this in the meta, since it
has tremendous potential in the marketplace, but by trying to push the
"smart" way on the marketplace directly, instead of in the teaching
order that the market apparently wants it, we have found ourselves
down blind alleys. The way the market wants to take things can
probably be shown not to optimize the best case for the world. But
Lisp, to succeed, must accomodate that lack of willingness, lack of
motivation, lack of vision, etc. that the market, as an entity, often
shows... Ignoring that reality can condemn the world to a bad score,
just as surely as designing the tool to score badly in the first place
can do. Or so it seems. But I didn't have a full night's sleep, and
maybe I'm either not quite coherent or I'm insightfully free
associating. Always hard to tell for sure which is which.
Dorai Sitaram
> as it stands,
> however, Scheme does proper homage to the Algol tradition, to which it
> was dedicated, at least as of R4Rs. (I personally think it's a serious
> mistake to try to marry Algol to Lisp, and Scheme is the bastard that
> came out of it, but this is not something I thought before I studied
> Scheme, it's a conclusion after watching the horrible messes people who
> like Scheme willingly get themselves into.)
It is true that some Algol blood is claimed for Scheme.
But that blood is purely in the area of textual block
structure (blocks introducing variables that were
lexically scoped), which Lisp did not have at the time.
Common Lisp shares this genetic heritage (although its
Algolism isn't as readily admitted).
I am with Rob et al that Scheme doesn't syntactically
distinguish between expressions and statements, but
rather underspecifies what some expressions ought to
return. For better or worse, the Scheme standard (at
least some of whose authors seem to have trafficked
heavily in "bottom" values) considers
underspecification to be quite all right. (Another
famous example of Scheme's willing underspecification
is the order of evaluation of procedure arguments.)
Sure, this drives some people nuts, but it shouldn't be
miscategorized as something else.
--d
Tim Bradshaw
> (1) Use an ambiguous expression and hope the person doesn't know
> you're being vague until you have a chance to explain. (This is
> what I'm trying to do, btw.)
> (2) Use a truthful expression that forces you to indulge a presentation
> order that might not be of your choosing.
> (3) Lie, and fix the lie later. (A modified version of this is to "color"
> the lie in a way that explains you are doing it, and then repair the
> lie later; I've experimented with this "explicit lying", too.)
>
I've tried (1) and (3) too. I think that (2) is typically not
workable because you end up having to teach a lot of stuff in an order
which is very unuseful for students. (1) is nice, if you can do it.
The problem is that if you get smart students, they will often pick it
up and then you end up either doing (2) or reverting explicitly to
(3).
What I ended up doing is lying but saying right up front that some
things would not be quite strictly true, and often saying `that was a
lie' when I said something.
The real problem with (2) with the `all forms return a value' and
order is that not only can forms return no or many values, they can
fail to return, and not just in cases where an error has happened:
(block foo
(setf y (return-from foo 3)))
Obviously that is a trivial case, but there are plenty of cases like
that that are *not* trivial. For instance I often use a trick of
passing and then calling a (downward) closure around that effectively
does a (return-from myblock ...) as a way of doing what CATCH and
THROW do except knowing exactly which block I am returning from.
--tim
Martin Rodgers
> What I ended up doing is lying but saying right up front that some
> things would not be quite strictly true, and often saying `that was a
> lie' when I said something.
This is what I'd call a "Penultimate Truth", after the PKD novel, which
concerns big lies about the Real World. While in the novel, this idea
only makes it easier for the government(s) to maintain their oppressive
power (or so it is suggested), I suspect that when teaching we get away
with it without suppressing the truth.
In fact, it seems to me that this is what our parents must've done when
we asked tough questions at an early age. In an ideal world, we might all
be able to deal with the ultimate truth right from birth, in reality we
don't learn about the Principia Mathmatica in pre-school.
My favourite model for teaching complex ideas is in SICP. There are four
languages described in that book, and each one is a subset of the next to
be presented. The implication might be that this sequence never ends, and
that we can continue extending it.
So, we may if we like see reality as layers of truth. I only object to a
teacher lying when there's no intention to reveal the next layer.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
Howard R. Stearns
Last night I did a foolish thing. I asked my six year old what 5-4
was. I then deliberately asked her what 4-5 was.
Fortunately, for reasons I don't remember, I had told her some time ago
that the numbers work backwards, too: ... 4 3 2 1 0 -1 -2 -3 -4 .....
Without even blinking, my daughter answered "negative one". This was
very fortunate, because if she didn't have the machinery to figure out
what was going on, she might have felt inadequate, confused, frustrated,
etc.
I believe that throughout my life, I have encountered problems in a
subject that I didn't yet have the machinery to think through. This
left me on a local maximum that made further progress impossible until I
forced myself (or was forced by a teacher) to retrace my steps, climb
back down the hill, and move on.
My conclusion is that if you could truly control all the problems which
might occur to a student, then you can stick to a linear path in
teaching them. Otherwise, if there is any chance of sticky issues (and
there ALWAYS is), then you have to at least INTRODUCE the other ideas
that give them at least the HOPE that there is some way in which this
problem can be understood. Let me repeat:
We don't have to define and describe every side issue that could
possibly come up, but we do have to point out the other branches along
the path. Often simply giving the other branch a NAME is sufficient.
It lets the student know that there is more material that can be applied
to a problem, and all they have to do is go back and learn it. I
believe this is much better than letting the student loose faith (in
himself or the teacher or the whole discipline), and then trying to fix
it later.
I have a philosophy in programming whereby, if I can't think of a good
name for something (a variable, function, etc.), then I assume that I
haven't given the whole problem enough though and am probably making a
mistake. I think the same thing applies to teaching: If we aren't able
to anticipate the screw cases and at least come up with names for the
necessary machinery to allow our students to deal with the screw cases,
then we need to reconsider the whole presentation. (In some cases, it
might indicate that that there is a problem not with the presentation,
but with the material itself -- i.e., that the subject being taught is
flawed.)
On last thought: I believe that it is at the boundaries of a subject
(i.e., the screw cases) that we really learn (internalize, master, etc.)
the subject. They should be part of normal teaching, and not avoided.