Yes, there are a few options with GitHub's version of Markdown.
One is to make that section a list and have the "In the above" parts be sub-points by indenting them two spaces. This is that:
Create a "world" in which the ATOMs of the argument LIST have
been SET to the values applied to the FUNCTION, and all other
ATOMs have their original values. This is called "binding".
In the above, this is a "world" in which X is SET to 5.
In that new "world", evaluate all the objects in the body of the
FUNCTION, one after the other, from first to last.
In the above, this means evaluate <* .X .X> in a "world" where
X is SET to 5.
Throw away the "world" created, and restore the LVALs of all
ATOMs bound in this application of the FUNCTION to their
originals (if any). This is called "unbinding".
In the above, this simply gives X back the local value, if any,
that it had before binding.
Return as a value the last value obtained when the FUNCTION's
body was evaluated in step (2).
In the above, this means return 25 as the value.
Another way would be to make them different paragraphs by putting blank lines between them and not indenting the "In the above" parts, like so:
Create a "world" in which the ATOMs of the argument LIST have
been SET to the values applied to the FUNCTION, and all other
ATOMs have their original values. This is called "binding".
-- In the above, this is a "world" in which X is SET to 5.
In that new "world", evaluate all the objects in the body of the
FUNCTION, one after the other, from first to last.
-- In the above, this means evaluate <* .X .X> in a "world" where
X is SET to 5.
Throw away the "world" created, and restore the LVALs of all
ATOMs bound in this application of the FUNCTION to their
originals (if any). This is called "unbinding".
-- In the above, this simply gives X back the local value, if any,
that it had before binding.
Return as a value the last value obtained when the FUNCTION's
body was evaluated in step (2).
-- In the above, this means return 25 as the value.
Please let me know which you prefer and I'll go with that.
Yes, there are a few options with GitHub's version of Markdown.
One is to make that section a list and have the "In the above" parts be sub-points by indenting them two spaces. This is that:
ATOM
s of the argumentLIST
have beenSET
to the values applied to theFUNCTION
, and all otherATOM
s have their original values. This is called "binding".X
isSET
to5
.FUNCTION
, one after the other, from first to last.<* .X .X>
in a "world" whereX
isSET
to5
.LVAL
s of allATOM
s bound in this application of theFUNCTION
to their originals (if any). This is called "unbinding".X
back the local value, if any, that it had before binding.FUNCTION
's body was evaluated in step (2).25
as the value.Another way would be to make them different paragraphs by putting blank lines between them and not indenting the "In the above" parts, like so:
ATOM
s of the argumentLIST
have beenSET
to the values applied to theFUNCTION
, and all otherATOM
s have their original values. This is called "binding".-- In the above, this is a "world" in which
X
isSET
to5
.FUNCTION
, one after the other, from first to last.-- In the above, this means evaluate
<* .X .X>
in a "world" whereX
isSET
to5
.LVAL
s of allATOM
s bound in this application of theFUNCTION
to their originals (if any). This is called "unbinding".-- In the above, this simply gives
X
back the local value, if any, that it had before binding.FUNCTION
's body was evaluated in step (2).-- In the above, this means return
25
as the value.Please let me know which you prefer and I'll go with that.