A fun tutorial for learning Guile.
Christopher Allan Webber
ee72c06ba2
Fixing escaping of slashes when talking about characters
|
8 éve | |
|---|---|---|
| .gitignore | 9 éve | |
| COPYING | 9 éve | |
| Makefile | 9 éve | |
| README | 9 éve | |
| simple-toys.skb | 8 éve | |
| tutorial.skb | 8 éve | |
| up-and-running.skb | 8 éve |
README
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
tutorial.
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.
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
tutorial.
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.