Ann: Sketchy LISP, Third Edition
Nils M Holm
Sketchy LISP
An Introduction to Functional Programming in Scheme
Blurb:
Sketchy LISP presents an overview of the Scheme programming language
with strong emphasis on functional programming. Language elements
and programming techniques are explained by means of simple examples
which are used to form more complex programs.
The first chapter of the book introduces basic concepts such as
definitions, conditional evaluation, recursion, procedures, and
elementary data types.
While the second chapter continues this tour, it puts emphasis on
more complex programs by introducing problems of varying complexity
and then outlining the way to their solution step by step.
The third chapter takes up some lose ends and briefly introduces
continuations, one of the more advanced features of Scheme. It also
demonstrates how Scheme can be viewed as a formal system by
constructing a Y combinator.
New in the third edition:
The third edition adds a fourth chapter that illustrates what
Scheme looks like in the "real world" by means of a more advanced
and heavily commented example program.
The indentation style in the examples is more consistent now,
which is particularly important to beginners. In addition, a
Scheme style guide was added to the appendix.
Acknowledgements
Thanks to all the people who sent me mail with great ideas on
how to improve Sketchy LISP!
Where to get it
The full text of this edition can be viewed online. Paper copies
and inexpensive PDF files can be purchased at Lulu.com.
Online Edition: http://www.t3x.org/sketchy/vol1/
Paper copies and PDF files: http://www.lulu.com/content/213736/
Thank you for your interest, I hope you will enjoy the new edition!
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Benjamin L. Russell
>Programming languages should be designed not by piling feature on top of
>feature, but by removing the weaknesses and restrictions that make
>additional features appear necessary.
>-- RnRS introduction
>
>Unfortunately this principle was abandoned in the R6RS process. I
>created this edition in the hope that enough people will stay interested
>in the small and beautiful language that Scheme used to be, so the R5RS
>will remain a de-facto standard.
Your statement sparked my curiosity, so I searched and came up with
the following list:
Revised^6 Report on the Algorithmic Language Scheme - Language Changes
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-19.html#node_chap_E
According to the above-mentioned list, among a variety of other
changes were the following ones apparently singular ones:
> * Libraries have been added to the language.
>
> * The old notion of program structure and Scheme’s top-level environment has been replaced by top-level programs and
libraries.
This leads to the following questions:
1) Are these points the ones you were referring to?
2) One of the main reasons that I preferred Scheme over Common Lisp
was the succinctness of Scheme, caused precisely by the of libraries.
One of the main reasons that I stopped studying Java was precisely
because of the huge growth in libraries. Do you feel that the points
above now give R6RS Scheme more of the feel of Common Lisp than of
R5RS Scheme? (If so, I have an ominous feeling of dark clouds
approaching....)
-- Benjamin L. Russell
Benjamin L. Russell
reposted a revised version here.)
In your Preface to your Third Edition, you write:
>Programming languages should be designed not by piling feature on top of
>feature, but by removing the weaknesses and restrictions that make
>additional features appear necessary.
>-- RnRS introduction
>
>Unfortunately this principle was abandoned in the R6RS process. I
>created this edition in the hope that enough people will stay interested
>in the small and beautiful language that Scheme used to be, so the R5RS
>will remain a de-facto standard.
Your statement sparked my curiosity, so I searched and came up with
the following list:
Revised^6 Report on the Algorithmic Language Scheme - Language Changes
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-19.html#node_chap_E
According to the above-mentioned list, among a variety of other
changes were the following, apparently singular ones:
> * Libraries have been added to the language.
>
> * The old notion of program structure and Scheme’s top-level environment
>has been replaced by top-level programs and libraries.
This leads to the following questions:
1) Are these points the ones you were referring to?
2) One of the main reasons that I preferred Scheme over Common Lisp
was the succinctness of Scheme, caused precisely by the lack of
libraries. One of the main reasons that I stopped studying Java was
precisely the huge growth in libraries. Do you feel that the points
above now give R6RS Scheme more of the feel of Common Lisp than of
R5RS Scheme? (If so, I have an ominous feeling of dark clouds
approaching....)
-- Benjamin L. Russell
On Wed, 6 Aug 2008 11:10:08 +0000 (UTC), Nils M Holm
<news...@t3x.org> wrote:
tfgordon
trouble to speak out against it in the preface of your new book.
But, honestly, is there any example in this book that couldn't have
been written in almost exactly the same way in R6RS Scheme? Indeed,
is there even a single example in the book which couldn't be run in
exactly the same way using Ikarus, Larceny, Mzscheme or Ypislon in
their R6RS modes?
Does the book provide any evidence for the supposed superiority of
R5RS?
-Tom Gordon
Nils M Holm
> Your statement sparked my curiosity, so I searched and came up with
> the following list:
>
> Revised^6 Report on the Algorithmic Language Scheme - Language Changes
> http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-19.html#node_chap_E
>
> >
>
> This leads to the following questions:
>
> 1) Are these points the ones you were referring to?
What I am refering to is primarily 1) the overall bloat, 2) unicode
in identifiers (which I think is a big mistake). IMO Libraries are
the one good thing that R6RS introduces. I guess I outlined my
concerns regarding R6RS already too often, but since you ask, here
is an incomplete list:
- Scheme source code now uses the Unicode character set.
Adds lots of ambiguity, makes code harder to read and edit.
- Identifiers and symbol literals are now case-sensitive.
Makes teaching and writing harder, because you can no
longer refer to Scheme syntax and procedures THIS-WAY.
Then there are lots of language constructs that should not be part
of the language, but should be implemented in *optional* libraries.
Including arbitrary constructs and procedures in the language just
because they may be useful to some people violates the spirit of
the original Scheme language.
Of course, this is just my opinion. Maybe R6RS is the future
(then I will eventually start looking for alternatives) or R5RS
remains a de-facto standard (which I sincerely hope). No matter
how it may come, my well-being does not depend on a programming
language, so I will be fine with it either way.
> 2) One of the main reasons that I preferred Scheme over Common Lisp
> was the succinctness of Scheme, caused precisely by the lack of
> libraries. One of the main reasons that I stopped studying Java was
> precisely the huge growth in libraries. Do you feel that the points
> above now give R6RS Scheme more of the feel of Common Lisp than of
> R5RS Scheme? (If so, I have an ominous feeling of dark clouds
> approaching....)
IMO libraries are a good thing, but R6RS missed the chance to
make them really portable by relying on a small core language.
The gap between Common Scheme and R6RS Lisp certainly narrowed.
The dark clouds are definitely there.
Nils M Holm
> But, honestly, is there any example in this book that couldn't have
> been written in almost exactly the same way in R6RS Scheme?
Sketchy LISP is a beginner's book. No, there are probably no such
examples. However, if the book would have covered R6RS Scheme, I
guess it would have had 380 pages rather than 180. This pretty
much sums up my point.
> Does the book provide any evidence for the supposed superiority of
> R5RS?
No.
tfgordon
> tfgordon <Thomas.Gor...@fokus.fraunhofer.de> wrote:
> > But, honestly, is there any example in this book that couldn't have
> > been written in almost exactly the same way in R6RS Scheme?
> Sketchy LISP is a beginner's book. No, there are probably no such
> examples. However, if the book would have covered R6RS Scheme, I
> guess it would have had 380 pages rather than 180. This pretty
> much sums up my point.
But surely a beginner's book need not cover the whole language, just
its
core features. I haven't read your book, sorry, but I suppose a
beginner's
book for R6RS wouldn't need to be much longer. It should probably
introduce libraries,
but it needn't cover all of R6RS's standard libraries, let alone other
libraries.
To make an analogy, a beginner's course in some foreign language
doesn't have
the ambition of teaching the whole language.
Does Sketchy LISP cover *all* of R5RS?
-Tom
namekuseijin
> >Programming languages should be designed not by piling feature on top of
> >feature, but by removing the weaknesses and restrictions that make
> >additional features appear necessary.
> >-- RnRS introduction
> 1) Are these points the ones you were referring to?
Perhaps he was talking about all those absurdist layers and long
procedure/macro names exposed just to define records. If bloat ever
had a name...
I prefer records the pascal way:
type person = record
name: string;
age: integer;
end;
I don't think Scheme is well suited for this. It's typeless by nature
and so defining typeful structures in an efficient and convenient
manner may not really be possible.
> 2) One of the main reasons that I preferred Scheme over Common Lisp
> was the succinctness of Scheme, caused precisely by the lack of
> libraries.
So, you like reinventing the wheel?
It's not like Scheme didn't have libs, just that it makes it pretty
clear about what is the core language and what is well suited for
libs. It even came with quite a few (very few) more convenient
procedures and macros defined in terms of core procedures. That was
pretty much its stdlib. OTOH, you have things like SLIB and the
SRFIs.
R6RS is still pretty much just about a (overly)well-defined core
language, not libs. The main additions besides unicode and case-
insensitiveness were modules (good) and records (good, but terribly
ill-defined). It doesn't come either with rich libs for doing IO,
threads, interfacing with the SO or whatever...
One more Scheme book is welcome, I guess.
leppie
> Perhaps he was talking about all those absurdist layers and long
> procedure/macro names exposed just to define records. If bloat ever
> had a name...
>
> I prefer records the pascal way:
> type person = record
> name: string;
> age: integer;
> end;
>
> I don't think Scheme is well suited for this. It's typeless by nature
> and so defining typeful structures in an efficient and convenient
> manner may not really be possible.
>
What's wrong with:
(define-record-type person (fields name age))
I think most people gets confused with the semantics with protocols in
the procedural layer.
Cheers
leppie
Pascal J. Bourguignon
Actually, defstruct takes in types for slots; and even default values
(in CL, I'm sure we can implement the same in scheme):
(defstruct person
(name string "Joe Doe")
(age integer 0))
The point being that lisp-class languages are not typeless. On the
contrary, they are even more typefull than the statically typed
programming languages, since those later drop all types at run-time.
And it's exactly because they're more typeful that programmers need
less to specify type (in a different way from, say, Haskell).
--
__Pascal Bourguignon__
namekuseijin
wrote:
> leppie <xacc....@gmail.com> writes:
> > On Aug 7, 12:22 pm, namekuseijin <namekusei...@gmail.com> wrote:
> >> I prefer records the pascal way:
> >> type person = record
> >> name: string;
> >> age: integer;
> >> end;
>
> > (define-record-type person (fields name age))
>
> (in CL, I'm sure we can implement the same in scheme):
>
> (defstruct person
> (name string "Joe Doe")
> (age integer 0))
Yes, that's nice. Unfortunately, Scheme has been turning more and
more verbose each iteration (call/cc, define-foo-bar-blurb etc) and
isn't still as convenient and typeful as the above.
> The point being that lisp-class languages are not typeless.
Sure. But that Scheme record is, so far.
> On the
> contrary, they are even more typefull than the statically typed
> programming languages, since those later drop all types at run-time.
They drop because they already tested and proved all expressions
correctly. Mantaining the types at runtime is only needed on those
occasions where you need to translate from user textual input to the
inner types the program uses. That is, all the time. :)
Benjamin L. Russell
<noelwelsh-Re5JQE...@public.gmane.org> wrote:
>2008/8/7 Benjamin L. Russell <DekuDekuplex-/E1597aS9LQ...@public.gmane.org>:
>> One of the main reasons that I preferred Scheme over Common Lisp
>> was the succinctness of Scheme, caused precisely by the lack of
>> libraries. One of the main reasons that I stopped studying Java was
>> precisely the huge growth in libraries...
>>
>> I have an ominous feeling of dark clouds approaching.... I just hope
>> that Scheme doesn't become the kind of monstrosity that Java and
>> Common Lisp have become, requiring constant flipping through huge
>> library reference manuals just to use. ...
>
>I don't understand this argument. Either your program benefits from
>libraries or it doesn't. If it does why wouldn't you use them, and if
>it doesn't why wouldn't you just ignore the libraries? For example,
>if you were writing an image processing program in Java you'd be
>bonkers to not at least look at the Java image API. You might then
>decide it doesn't fit your needs or is too hard to use, but I don't
>see how this can become a criticism of the language.
This is definitely the case for programmers who know what they are
doing. However, when I was starting out in my first course in
Computer Science, which used both Common Lisp and Scheme (and a
one-page translation chart, labelled "Common Lisp for Schemers,"
written by the professor, Drew McDermott, to let us do the exercises
in SICP in Common Lisp if we preferred), back in fall of 1990, we
used, if I remember correctly, a reference manual for Franz Lisp that
was over a thousand pages long that documented the available
libraries.
Being new to Common Lisp, I was afraid of reserved word name
conflicts, and didn't know how to avoid them yet, so I kept thumbing
through this huge reference manual every time I defined a new function
to ensure that the following conditions held:
1) I wasn't reinventing any functions that already existed, and
2) I wasn't redefining any reserved words.
Because I was still new to Common Lisp, I thought that all existing
function names were reserved words, and was afraid that renaming an
already-existing function would cause a naming conflict.
Because the level of this course was still introductory, some of the
other students actually told me that I could probably have done the
assignments faster by just ignoring this book and coding all the
elementary functions myself. Further, some of these students told me
that some of the existing functions were inefficient, and that I could
probably rewrite them myself to work faster, so that there was little
reason to use these functions. These statements caused even more
confusion, because I didn't know enough yet to distinguish between
inefficient and efficient functions just by looking at their code.
This book caused a lot of confusion for me in this class, because I
was still new to Common Lisp and thought that all existing function
names were reserved words that would cause errors if redefined, so I
spent about ten to fifteen minutes flipping through the book every
time I redefined a new function. I couldn't escape the feeling that
using such a huge reference for an introductory course was a mistake.
When a later course switched from Common Lisp to Scheme, which had a
much smaller community standards document, I was elated: The
assignments themselves did not require using the libraries, so I was
finally free to concentrate on the algorithms themselves, rather than
the libraries.
While libraries are definitely a benefit for professional programmers,
I believe that they can actually be a hindrance in an introductory
course in computer science, because of the following reasons:
1) They shift the focus from thinking about the underlying algorithms
to looking up libraries, and
2) They can cause confusion for some beginner-level students who might
think that each library function name is a reserved word that cannot
be redefined.
For beginners, keeping the language simple helps immensely. It is
very difficult for a beginning student to distinguish between what to
read and what not to read if the reference manual is over a thousand
pages long and other students say that some of the defined functions
are inefficient without explaining why they are inefficient. I just
hope that the changes in R6RS will not potentially affect the use of
Scheme in future introductory-level programming courses.
-- Benjamin L. Russell
Andrew Reilly
> While libraries are definitely a benefit for professional programmers, I
> believe that they can actually be a hindrance in an introductory course
> in computer science, because of the following reasons:
>
> 1) They shift the focus from thinking about the underlying algorithms to
> looking up libraries, and
>
> 2) They can cause confusion for some beginner-level students who might
> think that each library function name is a reserved word that cannot be
> redefined.
>
> For beginners, keeping the language simple helps immensely. It is very
> difficult for a beginning student to distinguish between what to read
> and what not to read if the reference manual is over a thousand pages
> long and other students say that some of the defined functions are
> inefficient without explaining why they are inefficient. I just hope
> that the changes in R6RS will not potentially affect the use of Scheme
> in future introductory-level programming courses.
Surely, given your description of your experiences, above, R6RS must be
an unequivocally better proposition than earlier revisions, simply
because of the clear delineation between "core language" and
"libraries". In particular, it is clear that unless you make the
appropriate incantation, the function names from the library are *not*
part of your environment. That makes the basic "teaching language" even
more straightforward than R5RS.
I have to admit that I have felt similarly, both when starting with
Common Lisp *and* with Java, having come from a C/Pascal/Fortran/Assembly
background. In both CL and Java, there are significant parts of the
language that have the surface appearance of a library function, but
which implements some significant fundamental mechanism of the language.
As I've become more comfortable with both, and with scheme, I've come to
the understanding that that's not necessarily such a bad thing, and the
sharp distinction between "language" and "code" that I was used to is not
the only way to separate those concepts: it can be a continuum. Still, I
lean towards favoring the sharper than the blurrier end of the spectrum
at the moment. Consequently, I really like PLT's module mechanism, and I
expect that I'll like R6RS, when I get around to using it.
--
Andrew
Pascal J. Bourguignon
> [...]
> Being new to Common Lisp, I was afraid of reserved word name
> conflicts, and didn't know how to avoid them yet, so I kept thumbing
> through this huge reference manual every time I defined a new function
> to ensure that the following conditions held:
>
> 1) I wasn't reinventing any functions that already existed, and
>
> 2) I wasn't redefining any reserved words.
>
> Because I was still new to Common Lisp, I thought that all existing
> function names were reserved words, and was afraid that renaming an
> already-existing function would cause a naming conflict.
And you were right! There's a specific section in chapter 11 that
prohibits redefining the operators of the package CL.
But you didn't need the book. Just a REPL:
C/USER[3]> (defun sin (category) (list 'bad category))
** - Continuable Error
DEFUN/DEFMACRO(SIN): #<PACKAGE COMMON-LISP> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
The following restarts are also available:
ABORT :R1 ABORT
C/Break 1 USER[4]> abort
C/USER[5]>
Or may be you needed reading the book more, to learn about packages
and how you could compose a package with only the CL symbols you
wanted.
C/USER[5]> (defpackage "MYLISP" (:use) (:import-from "CL" "DEFUN" "CAR" "CDR" "CONS" "NULL" "COND" "EQL" "CONSP"))
#<PACKAGE MYLISP>
C/USER[6]> (in-package "MYLISP")
#<PACKAGE MYLISP>
C/MYLISP[7]> (defun sin (category) (cons 'bad (cons category '())))
SIN
C/MYLISP[8]> (sin (cons 'kill (cons 'bill '())))
(BAD (KILL BILL))
C/MYLISP[9]> (+ 1 2)
*** - COMMON-LISP:EVAL: undefined function +
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of (COMMON-LISP:FDEFINITION '+).
RETRY :R2 Retry
STORE-VALUE :R3 You may input a new value for (COMMON-LISP:FDEFINITION '+).
ABORT :R4 COMMON-LISP:ABORT
C/Break 1 MYLISP[10]> :q
C/MYLISP[11]>
> When a later course switched from Common Lisp to Scheme, which had a
> much smaller community standards document, I was elated: The
> assignments themselves did not require using the libraries, so I was
> finally free to concentrate on the algorithms themselves, rather than
> the libraries.
Yes, scheme is a pedagogical programming language, like Pascal. Small
foot print, small report, fits in small heads of students. :-P
> While libraries are definitely a benefit for professional programmers,
> I believe that they can actually be a hindrance in an introductory
> course in computer science, because of the following reasons:
>
> 1) They shift the focus from thinking about the underlying algorithms
> to looking up libraries, and
>
> 2) They can cause confusion for some beginner-level students who might
> think that each library function name is a reserved word that cannot
> be redefined.
>
> For beginners, keeping the language simple helps immensely. It is
> very difficult for a beginning student to distinguish between what to
> read and what not to read if the reference manual is over a thousand
> pages long and other students say that some of the defined functions
> are inefficient without explaining why they are inefficient. I just
> hope that the changes in R6RS will not potentially affect the use of
> Scheme in future introductory-level programming courses.
>
> -- Benjamin L. Russell
Ok, but R5RS, with its 50-page report can be learnt entirely in one
week-end. What will you do the rest of the semester?
One day, you will have to start reading a book about Common Lisp and
its library, and learn about the library. Why not start in week 2?
And if you are afraid of these 1000+ pages of CL reference, what will
you say when you'll have to browse Apple or Microsoft or Sun
documentation websites for their libraries (Cocoa, whatever Microsoft
provides, Java stuff), where you have hundreds of thousand-page books.
Surely, as a student, you should learn how to use these big references.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
tfgordon
...
> While libraries are definitely a benefit for professional programmers,
> I believe that they can actually be a hindrance in an introductory
> course in computer science, because of the following reasons:
>
> 1) They shift the focus from thinking about the underlying algorithms
> to looking up libraries, and
>
> 2) They can cause confusion for some beginner-level students who might
> think that each library function name is a reserved word that cannot
> be redefined.
>
Well, R6RS Scheme isn't Common Lisp. For teaching purposes, a teacher
can use R6RS libraries to present students with a language as simple
as desired.
The predefined "base" library defines a language which, quaoting the
standard, "exports many of the procedure and syntax bindings that are
traditionally associated with Scheme."
If a teacher thinks this is still too much, he could define a custom
library for the course, exporting a subset of the base library.
And if one doesn't want students to have to first import this library,
a simple shell script could initialize the Scheme interpreter by
loading this library and entering a traditional, interactive read-eval-
print loop for the custom language defined by this library.
So I think your worries are unfounded. Relax. The dark clouds are
gone and the sun is shining brightly :-)
-Tom Gordon
Nils M Holm
> To make an analogy, a beginner's course in some foreign language
> doesn't have
> the ambition of teaching the whole language.
>
> Does Sketchy LISP cover *all* of R5RS?
Most of it.
Of course, a beginner's book need not cover the entire language,
but what do you do after learning the basics? In R5RS Scheme you
start doing interesting things with the concepts you learned. In
R6RS Scheme (like in Java, C++, Common Lisp), you start learning
"features".
It is creativity vs dull learning, and R6RS has made its position
on this quite clear. I predict that R6RS will contribute to a
further shift away from fun and creativity and towards learning
things that are needed to write dull, boring applications for
big companies that make money of them.
Benjamin L. Russell
Bourguignon) wrote:
>[...]
>
>Ok, but R5RS, with its 50-page report can be learnt entirely in one
>week-end. What will you do the rest of the semester?
How about learning how to be creative? Just take a look at such books
as SICP, Concrete Abstractions, and HtDP; you don't need a large
language to learn how to be creative; in fact, just the opposite.
I would cover topics such as the following:
* higher-order functions
* tail recursion
* tail calls
* accumulators
* continuations
* binary search trees
For more advanced students, I might then proceed on with a second
course covering the following topics:
* tree recursion
* memoization
* dynamic programming
* strictness/laziness
* non-determinism
None of these topics requires a large language. They do require the
ability to reason below the surface and to apply concepts creatively,
though. A larger language does not necessarily help here.
>One day, you will have to start reading a book about Common Lisp and
>its library, and learn about the library. Why not start in week 2?
>
>And if you are afraid of these 1000+ pages of CL reference, what will
>you say when you'll have to browse Apple or Microsoft or Sun
>documentation websites for their libraries (Cocoa, whatever Microsoft
>provides, Java stuff), where you have hundreds of thousand-page books.
>
>Surely, as a student, you should learn how to use these big references.
That probably depends partly on where the student is headed. Big
references are not necessarily important for research or self-study;
they may be useful for programming teams in big corporations. But we
already have Java for that; wasn't the whole point of Scheme to teach
students how to think creatively as programmers?
-- Benjamin L. Russell
samth
This is silly. The features that allow one to write creative programs
(such as higher-order functions, continuations, and macros) have not
been removed. In some cases, more fun and creativity is possible (as
with procedural macros). What's been added is the ability to do new
things, like handle errors, something that every student should know,
or structure a large program into multiple pieces, again an important
skill.
If creativity means merely writing trick programs that fit on a page,
then perhaps R5RS was sufficient, but R6RS is no worse. If creativity
means using the powerful features of the language to implement new and
exciting systems, then R6RS is a big improvement.
If what you would really prefer is that no one write programs that
don't interest you in your favorite language, I'm afraid you are bound
to be disappointed.
sam th
leppie
> This is silly. The features that allow one to write creative programs
> (such as higher-order functions, continuations, and macros) have not
> been removed. In some cases, more fun and creativity is possible (as
> with procedural macros). What's been added is the ability to do new
> things, like handle errors, something that every student should know,
> or structure a large program into multiple pieces, again an important
> skill.
>
> If creativity means merely writing trick programs that fit on a page,
> then perhaps R5RS was sufficient, but R6RS is no worse. If creativity
> means using the powerful features of the language to implement new and
> exciting systems, then R6RS is a big improvement.
>
> If what you would really prefer is that no one write programs that
> don't interest you in your favorite language, I'm afraid you are bound
> to be disappointed.
Well said, I agree with you 100%.
Cheers
leppie
Ray Dillinger
> This is silly. The features that allow one to write creative programs
> (such as higher-order functions, continuations, and macros) have not
> been removed. In some cases, more fun and creativity is possible (as
> with procedural macros). What's been added is the ability to do new
> things, like handle errors, something that every student should know,
> or structure a large program into multiple pieces, again an important
> skill.
Hm. Been a while since I looked in here, and I guess this issue
is why. R6RS alienated me in particular because it was a triumph
of making implementation convenient for bitbashers over mathematical
and design correctness.
Scheme turned itself into an inferior little brother of Common
Lisp. So now when I want a language with pure abstractions I
use my own lisp implementation, and when I want something that's
portable, allows bitbashing, and has a big library, I use Common
Lisp. Here, I find that the two camps are still staring at each
other and each not understanding the other's points. I will
explain briefly.
Up through R5, the standard was very deliberately a standard
that would *allow* an implementor to do "The Right Thing" if
that implementor desired a language with absolutely pure
abstractions. R6 *DISALLOWS* many things that would be better
for that kind of language than the ones on which it settles.
R6 is the very first scheme report that mandates things which
are manifestly wrong for a language with pure abstractions.
The problem, IMO, is about some fundamentals. Now that they've
been standardized, you can no longer use scheme to easily teach
how they are implemented. Nor can you easily use it to allow
students to experience the implications and results of different
implementations, interfaces and mechanisms for such fundamentals.
Moreover, some of them (error handling in particular) are wrong.
R6RS took a popular error-handling mechanism from imperative
OO languages with escape-only continuations, and bolted it onto
a functional language with escaping and reentering continuations,
and it does not fit correctly.
Some of them (character handling and numerics in particular) have
been standardized in ways that break abstraction rules and inherit
faint and fuzzy thinking from bitbashing languages. If we want
programming to be easy and programs to be clear, then we should
have to think about the binary representation of things only when
actually doing binary I/O. This is not true for characters and
numbers any more in R6.
A character should be an abstraction. You shouldn't have to think
about its binary representation, or how many codepoints your
particular current encoding takes to represent it. Character
and string operations should be exactly the same on a ternary
machine with 27-trit words and an encoding you've never heard of.
The fact that they are not shows that the abstraction has been
broken in favor of bitbashing on the binary representation of
characters according to a single standard.
In dealing with numbers, I think we should strive for exactness.
Exactness is a pure good, and it means you have answers you can
rely on. Imagine my dismay then, when R6 made it wrong to
give an exact result in some cases where an exact result is
available (examples: multiplication of an inexact number by an
exact zero, square roots of an exact square integer, etc). R6
did this because implementors deliberately confounded mathematical
information with representation information and wanted consistent
type equations for their operations. In fact it made exactness
information in Scheme no better than type information in Common
Lisp, so there's no point in using Scheme for exactness anymore.
Any striving for better methodology or representation that
preserves exactness in more situations, is now a violation
of R6. Was that a reasonable thing to sacrifice on the altar
of *&%$ binary-representation bitbashing?! I don't think it was.
Sure, there should always be room for implementors to *not* go
to heroic lengths for exactness, but I think that disenfranchising
anyone who wanted to do better, as opposed to faster, numerics
was a mistake.
In the design of uniform vectors, R6 created static type
declarations in a dynamically typed language. The only
graceful design for such things is as an optional declaration
whose removal does not change the semantics of correct programs.
Essentially, you're making a promise to the runtime here that
your program will never ever store anything in this variable
that isn't a member of this type. If the system uses this
information to eliminate a whole bunch of code paths it needed
to deal with other values, you get smaller and faster code. If
not, you still at least get correct code. That's not how R6
did it. In this case, copying the way Common Lisp does things
would have been much better than what they actually did.
Instead, R6 created a system that actually changes the values
of numbers by storing them; they are coerced to the type,
coerced to the exactness of the vector, and when you retrieve
them they may not be the same numbers you stored!
Next we have bitfields. Bitfields are not integers. Bitfields
have a definite binary width and integers don't. Numbers can
in principle be represented in different ways for efficiency,
fit on big- or little-endian machines, or for the preservation
of exactness in different operations, and bitfields can't.
Operating on numbers as bitfields, or on bitfields as numbers,
breaks an abstraction barrier and makes people have to care
about the binary representation of numbers. Bitbashing wins
and abstraction loses, AGAIN.
And.... dammit, I'll stop here. R6 contained a lot of bitter
disappointments. I've only hit a few of the high spots.
Bear
pnkf...@gmail.com
> In dealing with numbers, I think we should strive for exactness.
> Exactness is a pure good, and it means you have answers you can
> rely on. Imagine my dismay then, when R6 made it wrong to
> give an exact result in some cases where an exact result is
> available (examples: multiplication of an inexact number by an
> exact zero, square roots of an exact square integer, etc).
I do not think you are correctly reading the R6RS. The last two
paragraphs of section 11.7.1 of the language report explicitly address
the issues you raise here.
Brian Harvey
> So now when I want a language with pure abstractions I
>use my own lisp implementation
You don't have to go that far -- there are still R5RS Scheme interpreters
out there. :-)
Ray Dillinger
So they do. Now I'm trying to remember how I formed the mistaken
impression I conveyed above; I remember arguing about it on the
R6RS list and I was pretty sure I (and several others who agreed
that it would be good not to conflate exactness with type information)
had lost.
At this point though, my own lisp is doing something a bit different.
I have three kinds of exactness: Bignum, Exact, and Interval. By
default, all numbers encountered in source code are read as exact
numbers. If you want a number to be read as a bignum or as an
interval, there's a different numeric syntax for that. Exact
computations on exact numbers produce exact numbers when practical,
otherwise they produce Intervals. Computations on intervals usually
produce intervals, but in some cases (as above) may produce exact
numbers if the computation permits.
"Practicality" in this case means computable by methods I can code
and representable as a reasonably-small (<= 16-word) chunk of data.
Most numbers that can be printed on one line with scheme's syntax,
including ratios, decimal fractions, etc, can be represented exactly.
But the important point is that by default, propagation of exactness
is preserved where practical, but limited so as not to cause errors.
I find that very important on machines with finite memory, which is
most of them.
Bignums are a separate set of exact numbers. Any number that can
be represented exactly can also be represented as a bignum. And
all exact operations on bignums produce either bignums or out-of-
memory errors (hey, if I'm using bignums, I _signed_up_ for the out
of memory errors....). They have a distinct syntax from "normal"
exact numbers to make it so I don't use them by accident.
This reflects a simple principle: the default behavior of a
programming language should be that it does what you usually want.
If you want something odd, you should have to ask for it
explicitly. What I want usually is an exact answer if I can
get it, or a narrowest practically computable interval containing
the exact answer if I can't.
So that's what I made the default numerics do. If I want behaviors
that I consider suboptimal for most purposes (risking memory errors
with bignums or using an inexact/interval number where I didn't
have to in source and thereby abandoning hope for an exact answer)
I left myself a way to specify those behaviors.
R6 was liberating in a sense; once the standard started being silly
I no longer felt any pressure to conform to it. So I shifted focus
from "scheme with subtle semantic extensions that programmers probably
won't notice unless they actually use them" to "ah, heck, I always
wanted to design my own lisp." So, in addition to some wild
extensions to the semantics of function definition, which had been
my focus up to R6, I now feel free to play with such fundamentals
as numeric syntax and semantics.
Bear
Bradd W. Szonye
> A character should be an abstraction. You shouldn't have to think
> about its binary representation, or how many codepoints your
> particular current encoding takes to represent it. Character and
> string operations should be exactly the same on a ternary machine with
> 27-trit words and an encoding you've never heard of. The fact that
> they are not shows that the abstraction has been broken in favor of
> bitbashing on the binary representation of characters according to a
> single standard.
This sounds to me like reinventing the Unicode wheel in a gratuitously
incompatible way. You might be able to avoid some of Unicode's design
gaffes, but you'd surely just replace them with your own because of
limited and culturally-biased experience.
--
Bradd W. Szonye
http://www.szonye.com/bradd
George Neuner
wrote:
ISTM that Ray talked about his character design previously and said it
was based on 32-bit code points and would at least read Unicode - is
that no longer true?
Anyway, given how f_'d up Unicode processing can be unless you convert
to code points (not to mention the cultural biases already in Unicode)
I don't see how Ray trying to design something better is a bad thing -
particularly when he's trying to avoid some of the sticky processing
issues. Futile maybe, but not bad. It's his time to waste.
George
Ray Dillinger
> ISTM that Ray talked about his character design previously and said it
> was based on 32-bit code points and would at least read Unicode - is
> that no longer true?
It's true; one of the encodings my system reads and writes is unicode.
I'm not advocating a bizarre encoding. I'm advocating an abstraction
level where your characters behave like characters instead of having
user code bitbashing around in the encoding and having to care which
characters are precombined and which ones have separate modifier
codepoints.
And I don't want to get sucked into this argument again, so I'll stop
there. I've already ranted enough about unicode-centric systems.
Bear
George Neuner
wrote:
No argument - Unicode sucks!
George