I have recently started following the examples from The Little Schemer and when trying out the examples in DrScheme, I have realised that there are some minor syntax changes from the examples in the book to what I can write in DrScheme.
First of all, as a language in DrScheme, I chose Pretty Big (one of the Legacy Languages).
Is this the correct choice for trying the examples in the book?
As regards the syntax changes I have noticed that, for example, I need to prefix the identifiers with a ' in order for them to work.
For example:
(rember 'jelly '(peanut butter jelly))
Are there any more changes (syntactical or not) that I need to be aware of when trying the examples from the 'The Little Schemer' book ?
IIRC, the book uses a different font for quoted pieces of data, and in real Scheme code that requires using quote. As for your use of PLT Scheme -- the "Pretty Big" language is really there just as a legacy language. You should use the Module language, and have all files start with #lang scheme (which should be there by default).
(The "new" way of using different languages in DrScheme is to always be in the Module "language" and specify the actual language using a #lang line.)
See the "Guidelines for the reader" section in the Preface. (I'm looking at the 4th edition here.)
Related
My understanding of the history of Scheme macros is as follows:
R4RS introduced macros in the appendix. This was an expansion to the language rather than a part of the standard. It is essentially a library that appears in the R4RS document.
R5RS used a similar system to R4RS, but it was entirely a part of the standard rather than an extension.
R6RS and R7RS (small) have made minor upgrades/changes, but nothing substantial.
Any Scheme before R4RS did not feature any macros, except for fringe external libraries.
Is this correct? It seems generally right when I search through R4RS and anything after, but I'm struggling to find an easily-searchable copy of R3RS.
Scheme implementations had macros from the beginning, but the first real standard was R2RS, which did not include a macro system in the specification.
The original SCHEME paper, "SCHEME: An Interpreter for Extended Lambda Calculus" (AIM-349, 1975), also known as R0RS, presented a SCHEME interpreter written in MacLISP. Even this early description of a SCHEME interpreter discusses macros:
...SCHEME has a class of primitives known as AMACROS. These are similar to MacLISP MACROs, in that they are expanded into equivalent code before being executed.
The section goes on to describe some AMACROS which are provided with the SCHEME interpreter, including COND, AND, OR, BLOCK, and DO.
At the end of the paper a simple implementation of a SCHEME interpreter is presented, but the authors point out that "the 'production version' of SCHEME is coded somewhat more intricately." After presenting this implementation, they write:
AMACROs are fairly complicated beasties, and have very little to do with the basic issues of the implementation of SCHEME per se, so the code for them will not be given here. AMACROs behave almost exactly like MacLISP macros.
In R1RS, "The Revised Report on SCHEME: A Dialect of Lisp" (AIM-452, 1978), one finds:
C. Syntactic Extensions
SCHEME has a syntactic extension mechanism which provides a way to define an identifier to be a magic
word, and to associate a function with that word. The function accepts
the magic form as an argument, and produces a new form; this new form
is then evaluated in place of the original (magic) form. This is
precisely the same as the MacLISP macro facility.
These early macro systems were more traditional Lisp macro systems, akin to Common Lisp macros. Hygienic macros were introduced as a language extension in R4RS (1991), but not made a part of the Standard until R5RS (1998).
The early reports R0RS and R1RS were not really language standards so much as reports on the ongoing development of Scheme at MIT. In the introduction to R2RS (AIM-848, 1985) the authors say that 15 representatives of the major Scheme implementations convened to create a new standard because the implementations were starting to become too divergent. There was no macro system included in this new standard specification, but R2RS does say something about macros, including that all of the major implementations of the time did have macro systems:
Scheme does not have any standard facility for defining new special forms.
Rationale: The ability to define new special forms creates numerous problems. All current implementations of Scheme have macro facilities that solve those problems to one degree or another, but the solutions are quite different and it isn't clear at this time which solution is best....
R3RS (1986) had some similar language:
Macros
Scheme does not have any standard facility for defining new kinds of expressions. The ability to alter the syntax of the language creates numerous problems. All current implementations of Scheme have macro facilities that solve those problems to one degree or another, but the solutions are quite different and it isn’t clear at this time which solution is best, or indeed whether any of the solutions are truly adequate. Rather than standardize, we are encouraging implementations to continue to experiment with different solutions.
So I would say it is unfair to characterize macro systems prior to R4RS as "fringe libraries," and rather more fair to say the Scheme macro systems of the time were implementation-specific. Once macro hygiene was identified as an important issue, there was a concerted effort find the best solutions for hygienic macros within the Scheme community, and a fair bit of disagreement. This is the situation described in the above quotes from R2RS and R3RS with "...it isn’t clear at this time which solution is best...."
AIM-349 and AIM-452 (R0RS and R1RS) were really reports on the development of Scheme at MIT, and R2RS was the first real attempt at bringing disparate implementations together under a standard, i.e., R2RS was the first real standard for Scheme. Macros were present in the early implementations described by AIM-349 and AIM-452, but macros were left out of the standards to which implementations were required to adhere beginning with R2RS, until something approaching consensus was achieved on the topic; each implementation had its own approach to macros.
Resources
R3RS. This is a searchable pdf version, better quality than most of the scans I have seen online.
Hygienic Macro Technology. This is a pretty long paper by William Clinger and Mitchell Wand that describes the history of the development of hygienic macros.
I like to write code using org-mode and ob-racket. It works quite well for my purposes (mostly pragmatic scripting and solving code challenges as I slowly learn the patterns of this cool language). I am trying to understand language creation and a limitation is that ob-racket as is will only ever generate a single file for me, yet every example of creating a custom language I can find (largely just Beautiful Racket) uses separate files for the language definition and its usage.
I would assume - this being lisp after all - that it is possible to define a custom reader and/or a custom extender and then use them all in the same file. Can someone give me an example of how to do this or is it not doable?
I use Emacs everyday as it is the standard editor for Erlang.
I decided as my New Years Resolution to learn to programme eLisp. I decided that writing a book about eLisp was the best way to learn.
I have make pretty good progress:
Learn eLisp For Emacs
The strategic structure of the book is
getting started/basics
more advanced eLisp
writing a minor mode
writing a major mode
I have got through the basics (ie the first of these 4 points), covering:
evaluating expressions
debugging
adding menu items/toolbars
loading your own emacs files
etc, etc
If you are writing a book about a programming language you usually start by knowing the language well - well I don't - so my major problem now is a completeness problem:
How do I know that I have covered all the features that an Emacs programmer should have mastered?
How do I ensure that there aren't gaps in the content?
So I thought I would address these by asking the community here. My question is What Is Missing From My Table Of Contents? (in particular what should the more advanced eLisp Section contain).
Now that's an interesting way to learn a language...
I think you've probably skipped a bunch of the fundamentals in the getting started/basics section. If you've not already read it, I recommend reading "An Introduction To Programming In Emacs Lisp" (at gnu.org), which covers what I'd expect to see in the "basics" portion. I won't bother cut/paste the table of contents.
As far as knowing when you've written a complete book... Well, once you've re-written the Emacs Lisp manual in "how to" form, you know you're done. Alternatively, if you've written a book that can be used to answer/interpret all of the elisp and emacs questions, then you've probably got decent coverage.
What advanced features could you write about? There's advice, process communication, non-ASCII text, syntax tables, abbrevs, text properties, byte compilation, display tables, images, and a bunch more in the manual.
Note: The proper capitalization of elisp is either all lowercase, or possibly an uppercase E. The GNU documentation doesn't use "elisp" very much at all (mostly as a directory name, all lowercase), it prefers "Emacs Lisp."
Note: In the current version of your book, you treat global variables negatively. It's probably worth reading the RMS paper to gain some insight into the design decisions made, specifically on global variables as well as dynamic binding (the latter which you've yet to cover, which is a key (basic) concept which you've already gotten wrong in your book).
Instead of asking the community here, why not use what the community already offers? Review all the questions tagged "elisp" and see where they fit it your book. A survey of what people actually want to understand could be some of the best information you will get.
"I have read both the GNU manuals - but they are not so much use if you don't know Lisp/elisp."
Tip: Emacs is not much use if you don't know Lisp.
Not really true, of course, but you get the idea. This one is really true:
Tip: Emacs is much, much, much, much more useful if you know Lisp. Not to mention more fun.
Wrt what to learn:
symbols (they are simple objects, with properties -- not just identifiers)
lists -- cons cells, list structure (including modification/sharing)
evaluation
function application
regexps
text/overlay/string properties (values can be any Lisp entities)
buffers and windows
I'd suggest you'll take a look what the two Info manuals included with Emacs Emacs Lisp Intro "An Introduction to Programming in Emacs Lisp" and Elisp "The Emacs Lisp Reference Manual" already have to offer and then decide what you would like to add to or do differently than those.
If you port code over from one language to another, how can this be detected?
Say you were porting code from c++ to Java, how could you tell?
What would be the difference between a program designed and implemented in Java, and a near identical program ported over to Java?
If the porting is done properly (by people expert in both languages and ready to translate the source language's idioms into the best similar idioms of the target language), there's no way you can tell that any porting has taken place.
If the porting is done incompetently, you can sometimes recognize goofily-transliterated idioms... but that can be hard to distinguish from people writing a new program in a language they know little just goofily transliterating the idioms from the language they do know;-).
Depending on how much effort was put into the intention to hide the porting it could be very easy to impossible to detect.
I would use pattern recognition for this task. Think about the "features" which would indicate code-similarities. Extract these feature from each code and compare them.
e.g:
One feature could be similar symbol names. Extract all symbols using ctags or regular expressions, make all lower-case, make uniq sort of both lists and compare them.
Another possible feature:
List of class + number of members e.g:
MyClass1 10
...
List of method + sequence of controll blocks. e.g:
doSth() if, while, if, ix, case
...
Another easy way, is to represent the code as a picture - e.g. load the code as text in Word and set the font size to 1. Human beings are very good on comparing pictures. For another Ideas of code Visualization you may check http://www.se-radio.net/2009/03/episode-130-code-visualization-with-michele-lanza/
I recently downloaded PLT Scheme and DrScheme. When I open DrScheme, I am told to choose a language. However, I'm not familiar with any of my options, and the help guides don't really break it down to help me easily choose which choice.
So, first - is DrScheme and PLT Scheme really the tools I need to learn Lisp and/or Scheme? If so, what are the different languages and which one(s) should I be using?
Just go for "Pretty Big". That will be all you need until you know what the rest are for. I find that R5RS is good, but it does lack the extensions that PLT has added to DrScheme.
edit: I just checked and I guess that both "Pretty Big" and "R5RS" are considered "legacy" in DrScheme 4 and the "Module" language is favored instead. Just make sure that all the files you use with the Module language start with
#lang scheme
Module is a way to specify the language used in the source file rather than globally by the DrScheme interpreter. This means that you can use different languages for different parts of your program by breaking it up into files and indicating in each file the language you're using. If you're just starting out, all you need to worry about is just keeping #lang scheme at the top of all the files you use.
A small note - this declaration is not official Scheme, and needs to be removed if you attempt to use the files in another Scheme interpreter.
Standard (R5RS) is the actual thing so that would be your best bet
i learnt it from http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
used MIT Scheme while doing that
but otherwise i find plt a lot nicer to work with