Java has a reference implementation.
Does ISO-Prolog have a reference implementation?
I do have INCITS/ISO/IEC 13211-1:1995 (R 2007) so no need to suggest that.
EDIT
Of note: Conformity Testing I: Syntax
Let me first clarify what you mean by a reference implementation. You mean a sample implementation that is deemed to represent a valid interpretation of the standard. It is never clear what normative value such an implementation could have — think of the Java float syntax bug that made many systems loop.
There is no reference implementation for ISO Prolog. Like there is none for C, C++ or any other ISO/IEC standardized programming language. Please note that Java is not standardized by any standardization body like ISO, IEC, ITU nor CEN nor any national body like ANSI ; but rather by one company. And it is that very company that provides the reference implementation.
Also, Prolog exists since 1972 — long before any standardization took place. And it has been the first language of its kind and paradigm. It soon split into several different dialects with incompatible syntax (Prolog 1, Edinburgh, Prolog II etc.). One of the first standard related documents — Draft Proposed Standard for Prolog Evaluable Predicates by Richard O'Keefe was circulated 1984. BSI started 1984; AFNOR 1985. In 1987 the ISO process started, delivering ISO/IEC 13211-1 in 1995.
Contrast this to Java which evolved out of previous languages like C, C++ as well as other object oriented languages and inherited a lot from them. It had been developed quite differently with a company fiercely defending the language against all kinds of deviations — Think of it: even copies of the manuals were forbidden to be offered on the Internet.
In any case the Prolog systems with closest conformance are:
SICStus Prolog 4.3 beta 1. Not known to misread any valid Prolog text. Full support of Cor.1, Cor.2.
GNU Prolog 1.4.4 (git version). Not known to misread any valid Prolog text. Some differences in arithmetics. Otherwise Cor.1, Cor.2.
IF/Prolog V5. The only system offering a strictly conforming mode (see ISO/IEC 13211-1:1995 subclause 5.1 e).
A concrete comparison w.r.t. syntax (reading and writing) gives you a bit of an impression of what you can expect from these and other implementations.
Another implementation that provides a strictly conforming mode is ECLiPSe.
Use it with the -L iso_strict command line option.
Quoting from the compliance statement:
ECLiPSe provides an implementation of Standard Prolog as defined in ISO/IEC 13211-1 (Information Technology, Programming Languages, Prolog, Part 1, General Core, 1995) and the technical corrigenda ISO/IEC 13211-1 TC1 (2007) and TC2 (2012).
No. But GNU Prolog follows the ISO Prolog Core standard quite closely. Also note that it provides a strict_iso flag.
There are also other Prolog compilers that provide good standard compliance.
Directly from the SICStus Prolog manual, 4.3.0:
ISO Compliance
SICStus Prolog is fully compliant with the International Standard
ISO/IEC 13211-1 (PROLOG: Part 1—General Core)
as augmented by Technical Corrigenda 1 and 2.
To aid programmers who wish to write standard compliant programs,
built-in predicates and arithmetic functors that are part of the ISO
Prolog Standard are annotated with [ISO] in this manual.
Consider: The need to show compliance to a committee-issued technical document from 1995 except in a general way is hard to justify, unless you want to run a large amount of legacy code that cannot be updated for some reason. You want to run using modern ideas and features, not be compliant to premature normative references from ancient ages (when Sun workstations had 120 MHz CPUs and 24 MiB of RAM).
See also the chapter Positioning SWI-Prolog of the SWI Prolog manual.
In order to relieve people from searching, the list:
ISO/IEC 13211-1:1995 -- Information technology - Programming languages - Prolog - Part 1: General core
ISO/IEC 13211-2:2000 -- Information technology -- Programming languages - Prolog - Part 2: Modules
ISO/IEC 13211-1/Cor1:2007 -- Information technology - Programming languages - Prolog - Part 1: General core - Corrigendum (download free of charge)
ISO/IEC 13211-1/Cor2:2012 -- Information technology - Programming languages - Prolog - Part 1: General core - Corrigendum 2 (download free of charge)
Related
I need to do a presentation on a paper which at some point makes use of Isabelle/Isar and Isabelle/HOL.
I tried researching online about Isabelle/HOL and Isabelle/Isar to be able to eplain the relations in one or two slides.
Here are the relations as I currently understand them:
Isabelle - provides a generic infrastructure for deductive systems
Based on Standard ML programming language
provides an IDE which allows you to write theories which can be later be proved.
Isabelle/Pure - minimal version of higher-order logic according to this link:
Is it an actual language that can be inputted into isabelle IDE?
Or is it a technical specification?
Isabelle/HOL(Higher Order Logic):
Is it a library or a language?
How does it relate to Isabelle/Pure?
Is it procedural in nature?
Do tactics only exist in Isabelle/HOL?
Is it LCF - Logical Commutable Functions?
Isabelle/Isar:
Structured proof language based on Isabelle/Pure
Declarative
Is it an extension of Isabelle/HOL as stated at here?
Do locales only exist in Isabelle/Isar?
What does the Isabelle/IDE supports by default?
Just feels like I'm getting conflicting information from different sources and would like to sort this out.
Thanks in advance
Edit - Check out this highly related question and Manuel Eberls answer here: What are all the isabelle/slashes?
As this is an answer to a homework question and I myself only have limited understanding of all parts of the Isabelle project, this answer merely tries to point you in the right direction for at some parts of your question.
From the Isabelle/ISAR reference manual:
The Isabelle system essentially provides a generic infrastructure for building deductive systems (programmed in Standard ML), with a special focus on interactive theorem proving in higher-order logics.
It continues to also introduce ISAR:
In contrast Isar provides an interpreted language environment of its own,
which has been specifically tailored for the needs of theory and proof development.
[...]
The main concern of Isar is the design of a human-readable structured proof
language
Let's try to connect Pure to all of this by looking at publications from Makarius Wenzel regarding the topic:
Thus Isar proof texts may be understood as structured compositions of formal entities of the Pure framework, namely propositions, facts, and goals
In colloquial terms, Pure is the semantic foundation. Isar is a language that "follows" this semantic and provides syntax for it. Isabelle is just (one of the) platforms it all runs on.
Some of your confusions around the distinction between Pure and Isar seem to stem from the fact that the Isabelle Pure source code defines, or at least seems to define, both the semantics (Pure) and the syntax (Isar) in one go:
(* The Pure theory, with definitions of Isar commands and some lemmas. *)
In my humble opinion, this might be related to your understanding of syntax, semantics and "implementations" of the two. "Pure" outside of computers or paper is just semantics and thus, like math, just a thing in our brains. Give it syntax and you can put it to paper or type it into a machine. For the machine to be able to process your text (since this is ultimately what we after), it needs an implementation. Some framework telling it how to read the syntax and how to then process it. This framework is Isabelle. On top of Isabelle, there is Isabelle/Pure, which defines the semantics (the processing) and Isabelle/Isar, which defines syntax. For practical reasons, Isabelle's Pure implementation already provides the Isar syntax in one go.
From all of this, you might be able to figure HOL out yourself!
Some more references:
The Isabelle/Isar Implementation
I tried googling and read some snippets online. Why is Ada a "safety critical" language? Some things I notice are
No pointers
Specify a range (this type is an integer but can only be 1-12)
Explicitly state if a function parameter is out or in/out
Range-based loops (To avoid bound errors or bound checking)
The rest of the syntax I either didn't understand or didn't see how it helps it to be 'safety critical'. These are some points but I don't see the big picture. Does it have design-by-contract that I am not seeing? Does it have rules that make it harder for code to compile (and if so what are some?) Why is it a 'safety critical' language?
Well, this is pretty simple. The reason there's a lot of Ada sytax that doesn't seem to have much of anything to do with making the language "safety-critical" (whatever that means for a language) is that this was not Ada's design goal. It was designed to be a general-purpose compiled system's programming language, sufficently capable that the U.S. Department of Defense could get rid of all its little one-use languages it had to support all over the place.
The fact that the end result is a language that is rather useful for safety-critical applications was just a happy side-effect of the fact that the language was very well-designed with military applications (where lives are often staked on the software's reliability) in mind.
Surprisingly few other modern languages had support for building reliable software as a design goal. Most seem to be cooked up by a lone "genius" hacker, with the chief goal being the ability to facilitate cranking out lots of code quickly, perhaps in some new way that hacker favors.
All of those are good for safety-critical application; but consider also the ability to assign a layout (down to the bits) and the ability to [optionally] specify that such a record can ONLY be at a certain location (useful for things like video-memory mappings).
Consider that a lot of safety-critical applications are also without standard (in the senses both of "wide-spread" and of forward-comparability) interfaces; example: nuclear reactors, rocket engines (the engineering itself differs from generation to generation*), models-of-aircraft.
The upcoming Ada 2012 standard DOES have actual contracts, in the form of pre- and post-conditions; example (taken from http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf):
generic
type Item is private;
package Stacks is
type Stack is private;
function Is_Empty(S: Stack) return Boolean;
function Is_Full(S: Stack) return Boolean;
procedure Push(S: in out Stack; X: in Item)
with
Pre => not Is_Full(S),
Post => not Is_Empty(S);
procedure Pop(S: in out Stack; X: out Item)
with
Pre => not Is_Empty(S),
Post => not Is_Full(S);
Stack_Error: exception;
private
-- Private portion.
end Stacks;
Also, another thing that gets glossed over, is the ability to exclude Null from your Access/pointer types; this is useful in that you can a) specify that exclusion in your subprogram parameters, and b) to streamline your algorithm [since you don't have to check for null at every instance-of-use], and c) letting your exception handler handle the (I assume) exceptional circumstance of a Null.
* The Arianne 5 disaster occurred precisely because the management disregarded this fact and had the programmers use the incorrect specifications: that of the Arianne 4.
AdaCore has a nice presentation of various safety features of Ada 2005 here:
http://www.adacore.com/knowledge/technical-papers/safe-secure/
The US Government and industry also ran studies on program reliability a long time ago that compared languages. I couldn't find one very quickly as the sites are all old (!) but here's a quote from DDCI's website you: " In studies conducted during the eighties Ada consistently outperformed established programming languages like Pascal, Fortran, and C. In the nineties, Ada continues to surpass C++ in performance evaluations measuring capability, efficiency, maintenance, risk, and lifecycle cost."
Lists reasons they used it on Commanche project in link below. I'll add that the platform implementations have been around for a LONG time and stayed stable. Like a source in article said, maintenance is where majority of costs come in. We've seen the modern contenders .NET and Java change like crazy. Long-term stability of Ada is better for safety-critical apps which are often fielded for long periods (sometimes decades).
http://www.ddci.com/displayNews.php?fn=programs_rah66.php
Another benefit is Ada was designed for cross-language development. I keep seeing in the news people talking about how .NET and JVM are innovative b/c they let you mix the "right tools for the job" into one system. Ada's had that ability for a long time. It's common for apps to be a mix of Ada, C, C++, assembler, etc. (MULTOS CA comes to mind.) And they still function well.
It hasn't been static either. They keep updating the language, most recently in 2012. Its portability allowed it to run on both JVM and .NET too for people that want the libraries or have plenty existing code on those. There's also Ada development tools and robust runtimes for many OS's and RTOS's from IBM, Aonix, AdaCore, and Green Hills.
Last benefit: if it will compile, it will work. Usually.
I know this is late, but it's an example I recently encountered. I wrote the following C++ function that worked fine in -O0:
size_t get_index(const Monomial & t, const Monomial & u) {
get_index(t, u.log()); // forgot to type "return" first...
}
This actually compiles, and while it might emit a warning if you're lucky to have a decent compiler, you're not likely to see it when it's one of a lot of programs being compiled. Miraculously, it ran just fine when I compiled it with -O0. But when I compiled it in -O3 it crashed every time, and for the life of me I couldn't figure out why, because I didn't see the warning (if it even appeared). Imagine debugging that when you think you imagine a return there simply because you know your intent.
Likewise, back when I was learning C I frequently made this mistake:
int a;
scanf("%d", a); /* left out & before the a */
Using int's for pointers and vice versa is considered normal programming practice in C, so much so that compilers 25 years ago didn't even bother to emit a warning. Heck, that was a feature of C, not a bug. (See, for instance, Brian Kernaghan's "Why Pascal is not my favorite Language.") And of course back then home computer OS's didn't have memory protection; if you were lucky the computer wasn't writing to hard disk when it reset.
These kinds of mistakes won't even compile in Ada. Functions have to return a value, and you cannot accidentally use an Integer in place of an access Integer (i.e., pointer to integer).
And that's just the start!
Ada has superior support for real-time http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-1-3-4.html . This allows the programmer to implement a greater degree of determinism rather than worry about the technical details of the programming language itself. While many of the run-time features supported by Ada can be achieved in C with some deep understanding of things, Ada achieves most real-time features very well since it's standardized. Ada even has a Ravenscar profile http://en.wikipedia.org/wiki/Ravenscar_profile and SPARK a computer language where "highly reliable operation is essential" is based on a subset of Ada 83 and 95 http://en.wikipedia.org/wiki/SPARK_%28programming_language%29. My guess is that SPARK does not have a version for later Ada versions b/c it is too early to tell how safe the newer versions really are. It's also mentioned in the latter article that Ada can be optimized for speeds rivaling C which would be important for real-time applications that relied on precise control during rapidly changing events. There are many built in standard features for real-time control which are obviously important for a 'safety critical' language.
By Logic Programming I mean the a sub-paradigm of declarative programming languages. Don't confuse this question with "What problems can you solve with if-then-else?"
A language like Prolog is very fascinating, and it's worth learning for the sake of learning, but I have to wonder what class of real-world problems is best expressed and solved by such a language. Are there better languages? Does logic programming exist by another name in more trendy programming languages? Is the cynical version of the answer a variant of the Python Paradox?
Prototyping.
Prolog is dynamic and has been for 50 years. The compiler is liberal, the syntax minimalist, and "doing stuff" is easy, fun and efficient. SWI-Prolog has a built-in tracer (debugger!), and even a graphical tracer. You can change the code on the fly, using make/0, you can dynamically load modules, add a few lines of code without leaving the interpreter, or edit the file you're currently running on the fly with edit(1). Do you think you've found a problem with the foobar/2 predicate?
?- edit(foobar).
And as soon as you leave the editor, that thing is going to be re-compiled. Sure, Eclipse does the same thing for Java, but Java isn't exactly a prototyping language.
Apart from the pure prototyping stuff, Prolog is incredibly well suited for translating a piece of logic into code. So, automatic provers and that type of stuff can easily be written in Prolog.
The first Erlang interpreter was written in Prolog - and for a reason, since Prolog is very well suited for parsing, and encoding the logic you find in parse trees. In fact, Prolog comes with a built-in parser! No, not a library, it's in the syntax, namely DCGs.
Prolog is used a lot in NLP, particularly in syntax and computational semantics.
But, Prolog is underused and underappreciated. Unfortunately, it seems to bear an academic or "unusable for any real purpose" stigma. But it can be put to very good use in many real-world applications involving facts and the computation of relations between facts. It is not very well suited for number crunching, but CS is not only about number crunching.
Since Prolog = Syntactic Unification + Backward chaining + REPL,
most places where syntactic unification is used is also a good use for Prolog.
Syntactic unification uses
AST transformations
Type Inference
Term rewriting
Theorem proving
Natural language processing
Pattern matching
Combinatorial test case generation
Extract sub structures from structured data such as an XML document
Symbolic computation i.e. calculus
Deductive databases
Expert systems
Artificial Intelligence
Parsing
Query languages
Constraint Logic Programming (CLP)
Many very good and well-suited use cases of logic programming have already been mentioned. I would like to complement the existing list with several tasks from an extremely important application area of logic programming:
Logic programming blends seamlessly, more seamlessly than other paradigms, with constraints, resulting in a framework called Constraint Logic Programming.
This leads to dedicated constraint solvers for different domains, such as:
CLP(FD) for integers
CLP(B) for Booleans
CLP(Q) for rational numbers
CLP(R) for floating point numbers.
These dedicated constraint solvers lead to several important use cases of logic programming that have not yeen been mentioned, some of which I show below.
When choosing a Prolog system, the power and performance of its constraint solvers are often among the deciding factors, especially for commercial users.
CLP(FD) — Reasoning over integers
In practice, CLP(FD) is one of the most imporant applications of logic programming, and is used to solve tasks from the following areas, among others:
scheduling
resource allocation
planning
combinatorial optimization
See clpfd for more information and several examples.
CLP(B) — Boolean constraints
CLP(B) is often used in connection with:
SAT solving
circuit verification
combinatorial counting
See clpb.
CLP(Q) — Rational numbers
CLP(Q) is used to solve important classes of problems arising in Operations Research:
linear programming
integer linear programming
mixed integer linear programming
See clpq.
One of the things Prolog gives you for free is a backtracking search algorithm -- you could implement it yourself, but if your problem is best solved by having that algorithm available, then it's nice to use it.
The two things I've seen it be good at is mathematical proofs and natural language understanding.
Prolog is ideal for non-numeric problems. This article gives a few examples of some applications of Prolog and it might help you understand the type of problems that it might solve.
Prolog is great at solving puzzles and the like. That said, in the domain of puzzle-solving it makes easy/medium puzzle-solving easier and complicated puzzle solving harder. Still, writing solvers for grid puzzles and the like such as Hexiom, Sudoku, or Nurikabe is not especially tough.
One simple answer is "build systems". The language used to build Makefiles (at least, the part to describe dependencies) is essentially a logic programming language, although not really a "pure" logic programming language.
Yes, Prolog has been around since 1972. It was invented by Alain Colmerauer with Philippe Roussel, based on Robert Kowalski's procedural interpretation of Horn clauses. Alain was a French computer scientist and professor at Aix-Marseille University from 1970 to 1995.
And Alain invented it to analyse Natural Language. Several successful prototypes were created by him and his "followers".
His own system Orbis to understand questions in English and French about the solar system. See his personal site.
Warren and Pereira's system Chat80 QA on world geography.
Today, IBM Watson is a contempory QA based on logic with a huge dose of statistics about real world phrases.
So you can imagine that's where it's strength is.
Retired in 2006, he remained active until he died in 2017. He was named Chevalier de la Legion d’Honneur by the French government in 1986.
Will there be a functional language which does for the Java community what F# does for the .NET community?
What functional programming languages are available, or in development, for the JVM?
Scala would be the language.
Though not strictly functional (it's a mix of functional and object-oriented) and it is not strictly for Java (there is a .NET version of Scala), that would be the closest analog to F# in the JVM.
The first thing that came to my mind was Scala but really Ocaml-Java comes closer as F# is a variant of Ocaml. See this post that compares Ocaml-Java to Scala:
OCaml programmers are typically over 10x as productive as Java or C++
programmers for a wide range of practical tasks. Despite being based upon a
fundamentally OOP platform, F# goes a long way to capturing the productivity-
boosting benefits of OCaml (and the whole ML family). In contrast, Scala
fails to capture many of the benefits including some really basic ones and,
consequently, writing correct code is much more difficult in Scala than in
any real ML.
Moreover, the ML family of languages are designed to be succinct but Scala is
needlessly verbose for everything from "Hello world!" upwards. The ML family
of languages provide extensive type inference (OCaml more than most) but
Scala has only rudimentary inference by comparison. OCaml has an unusually
expressive type system but Scala adds little to OOP that is of practical
importance.
Perhaps Clojure. It's not statically typed, but it has more of an emphasis on immutability and concurrency than F#. However, like F# (and unlike Common Lisp), it is intended to be a primarily functional language that is good at consuming OO libraries from the underlying platform.
For now I would say Scala. But for the future, I'd have a look at Fortress. The first implementation of the spec was released on April 1, 2008. And no, that is not a joke. Key featues are:
Statically typed, but a lot of type inference to avoid clutter
Unicode and 2d rendering of mathematical functions
Designed for parallel execution (for each defaults to it)
Strong support for custom libraries (Guy Steele's influence)
Operator overloading, including the juxtaposition operator
More info at the Project Fortress Community website and the Wikipedia Fortress page.
Arguably none because the JVM lacks tail calls and they are required to make almost all functional code robust with respect to stack consumption.
The nearest thing to functional language implementations on the JVM are Clojure, Scala and the OCaml-Java project. Although there are workarounds for the lack of tail calls (e.g. trampolining), none of these language implementations do this because the workarounds introduce even more serious problems, e.g. crippling performance and completely obfuscating debugging.
Sun have been talking about tail calls for years and, more recently, have indicated that they intend to implement them imminently. As soon as that is done, I am sure we will see a lot more language diversity on the JVM and, in particular, some production-quality functional language implementations. Until then, I regard all of these languages as toys.
Cheers,
Jon Harrop.
There's a good list of programming languages for JVM, including functional programming paradigm and other paradigm languages on:
en.wikipedia.org/wiki/List_of_JVM_languages
My first pick is Scala (multi-paradigm; OO & FP), I spent a 5+ months studing Scala in 2009, and created a quick reference sheet: bchiprog.blogspot.com/2009/05/scala-cheat-sheet.html
I noticed there are other programming paradigms that are interesting, other focuses on parallel processing such as X10, Fortress, and Chapel. X10 is implemented on top of Scala - http://www.scala-lang.org/sites/default/files/odersky/scalaliftoff2009.pdf
It's really based on what problem you need to solve then pick the language that can best solve it. I think it's developers' wish that there's one language that can solve any type of problem easily and doing it simply.
#Marc Gravell - functional languages are increasingly used in the guts of enterprise grade financial systems. We use many functional (pure or "semi-pure") at the bank I work for...
Meanwhile, there is Frege, a pure functional, non-strict language in the spirit of Haskell that compiles to Java, which then is compiled further with javac or the eclipse compiler, depending on the environment (command-line or eclipse).
Actually, I might be wrong, but I don't expect F# to be as mainstream as the other .NET languages; useful in a few circles (academic, compilers, a few other scenarios) - however, don't forget that C# offers FP usage - and it gets better each time: C# 1.2 has delegates; C# 2.0 has anonymous methods and captures/closures; C# 3.0 has lambdas for simplicity, and Expression for abstraction. Anonymous types (C# 3.0) share some similarity with tuples (in terms of convenience), but obviously are very different beasts, so definitely not a like-for-like comparison.
Maybe not quite as optimised as F#, but for most day-to-day FP use-cases, more than sufficient.
It is also quite clear that better support for immutability (especially for threading) is very much on the minds of the C# language team for future consideration.
My money is on C# getting better at FP, and being the .NET FP offering for most day-to-day purposes. Of course, there will be some F# usage - but (purely subjective) I simply don't see there being a huge migration.
I would add https://eta-lang.org to the suggestions -- it's basically a Haskell for the JVM. I think the question is in line with the fact that F# is an ML language, while Clojure is a dialect of LISP.
Suppose I want to implement an interpreter for a functional language. I would like to understand the issues involved in doing so and suitable literature that is available. This is a new language that is in early design stages, that is why the question is broad in scope.
For the purpose of this discussion we can assume that the purpose of the language is not important and that its functional features can be changed (even drastically) if it makes a significant difference in the ease of writing an interpreter.
The MIT website has an online copy of Structure and Interpretation of Computer Programs as well as videos of the MIT 6.001 lectures using Scheme, recorded at HP in 1986. These form a great introduction to language design.
I would highly recommend Structure and Interpretation of Computer Programs (SICP) as a starting point. This book will introduce the idea of what it means to write an interpreter (and a compiler), and is generally a must-read for anybody designing languages.
Implementing an interpreter for a functional language isn't likely to be too much different from implementing an interpreter for any other general purpose language. There's lexical analysis, parsing, AST construction, semantic analysis, plus execution (for a pure interpreter) or code generation and optimisation (for a compiler, even compiling to bytecode like Java/Perl/Python). SICP will introduce the difference between "applicative order" and "normal order" evaluation, which may be important for you in a pure functional context.
For just about any language interpreter or compiler, the main issues are the same, I think.
You need to decide certain basic characteristics of the language (semantics, not syntax), and the bulk of the design of the thing follows from that.
For example, does your language have
a type system? If so, what sorts of
types does it have? Is it going to be
statically typed, dynamically typed,
duck-typed?
What sort of expressions are you
planning to support? Do you need to
define an order of operations? Will
you even have operators?
What will you use as the run-time
representation of the program? Will
you convert the text to a byte-code
representation, or an AST, or a
tokenized form of the source text?
There are toolkits available to help take some of the tedium out of the actual parsing of text (ANTLR and Bison, to name two), but I don't know of anything that helps with the actual interpretation part of the task. I'm sure somebody will suggest something.
The main issue is having a semantics for the language you're implementing -- with that, the implementation becomes straightforward. Otherwise, this question is incredibly broad and hard to answer.
I'd recommend Essentials of Programming Languages as a good complement to SICP, particularly if you're interested in interpreters: Official EOPL site. You may want to check out the third edition-- the site hasn't been updated for it yet.
Edit: spam prevention is making me choose between links, so the official page is now unheated. It's easily Google-able, though.