A fun tutorial for learning Guile.

Christopher Allan Webber ee72c06ba2 Fixing escaping of slashes when talking about characters 2 years ago
.gitignore be09fbdd33 Ignore .html files 2 years ago
COPYING dc5e436152 adding LGPL license 2 years ago
Makefile dd4381e986 Move "Up and running" section to its own file 2 years ago
README 4bd25fb98f Added a README 2 years ago
simple-toys.skb ee72c06ba2 Fixing escaping of slashes when talking about characters 2 years ago
tutorial.skb eb114a18e8 Reorganizing comments on where things should go in tutorial.skb 2 years ago
up-and-running.skb 1fd400f92c Switching "$1 = foo" style results to ";; => foo" style, and explaining variables 2 years ago


This document is released under the LGPL v3 or later, and GFDL v1.3 or
later, as published by the FSF (including this file!)

I hope it's helpful generally to you in learning how Guile works.
Patches welcome, also!

A note on style

I tried to set up the format of documentation so that patching it
should be easy while keeping the source readable. To demonstrate,
here's an example:

(p [You also might build up some fun toys while running through this
You might want to play with them and re-use them without having
to type them in all over again.
This is where your text editor comes into play!
Try opening a new file, we'll call it "sandbox.scm".
When you build something in this tutorial you'd like to use
over and over again without retyping it between REPL sessions,
you can put it here.
Let's try putting something there now:])

What you'll notice is that each new sentence starts on its own line.
Sentences which have characters which continue beyond line 79 "wrap",
but are indented to be clear that they align with a previous sentence.

This is an unusual convention, but I think a sane one: my usual
temptation is to use emacs' fill-paragraph technique to keep things
looking nice in plaintext, but that can entirely rearrange paragraphs,
and in my experience makes merging changes hard. I heard the
recommendation a while ago that keeping a sentence on its own line is a
better way to go for version-controlled documentation, but usually that
ends up flying off beyond column 80, and I hate that. So the above
approach merges the two.