\n"..
"\n"..
Q(two_d_trim(body))..
"\n"..
" |
$body" ]]
def [[ PRESTYLE 2 style,body "$body" ]] def [[ BORDERLESSTABLE 1 body "
| \n".. body.." |
A paragraph
][/tmp#] ] [P Let's understand what happened.] [P The first thing that blogme3.lua does is to extract from [' arg[0]] the directory where blogme3.lua resides, and add it to the path (the code is [_ here]; then it loads some files, with] [BE' -- (find-blogme3file "blogme3.lua") require "brackets" -- (find-blogme3 "brackets.lua") require "definers" -- (find-blogme3 "definers.lua") require "charset" -- (find-blogme3 "charset.lua") require "anggdefs" -- (find-blogme3 "anggdefs.lua") require "elisp" -- (find-blogme3 "elisp.lua") require "options" -- (find-blogme3 "options.lua") ] [P then it processes the command-line arguments.] [P For each recognized command-line argument there is an entry in the table _O - defined in options.lua - that describes how to process that option; for example, for "-i" we have this:] [BE' -- (find-blogme3 "") _O["i"] = dooptions_i dooptions_i = function () ... end ] [P The loop that processes the options is this simple recursion, in blogme3.lua:] [P The argument following "-o" is the name of the output file; as we shall see (in sec ___), some setup actions can only be performed after "-o" - for example, all definitions that depend on the base directory for relative links.] [P The option "-i" treats the argument following it as the name of an input file to be evaluated "in the normal way"; the contents of foo.blogme are evaluated as a "vrest", and the result of this is discarded (that's why the "Blah" at the end of foo.blogme disappeared!), but the contents of the global variable _output are written to the output file, whose name is the global variable _. If either outfile or the outcontents were empty we would get an error - but htmlize treated its first argument ("Foo bar") as the title of the html page ([Q [' "[J Foo bar]" -> "Foo bar"]]), used the "rest" of its arguments ([' "[P A paragraph]"]) as the body of the html, wrapped that within html headers, and stored the result in outcontents.] [P The word "lua:"] [P (...)] [RULE -------------------------------------------------------] [H2 A more precise description] [P The core of Blogme is made of a parser that recognizes a very simple language, and an interpreter coupled to the parser; as the parser goes on processing the input text the interpreter takes the outputs of the parser and interprets these outputs immediately.] [P This core engine should the thought as if it had layers. At the base, a (formal) grammar; then functions that parse and recognize constructs from that grammar; then functions that take what the parser reads, assemble that into commands and arguments for those commands, and execute those commands.] [P I think that the best way to describe Blogme is to describe these three layers and the implementation of the top two layers - the grammar layer doesn't correspond to any code. Looking at the actual code of the core is very important; the core is not a black box at all - the variables are made to be read by and changed by user scripts, and most functions are intended to be replaced by the user eventually, either by less simplistic versions with more features, or, sometimes, by functions only thinly connected to the original ones.] [sec «ancestors» (to ".ancestors") H2 [++N]. Ancestors] [# H2 Influences and rationale] [P I know that it sounds pretentious to say that, but it's true... Blogme descends from three important "extensible" programming languages - Forth, Lisp, and Tcl - and from several] [P The design of Blogme was inspired mainly by - or borrows ideas from - Forth, Lisp, and Tcl.] [sec «Forth» (to ".Forth") H3 [++NN]. Forth] [P This is a Forth program that prints "[TTFORTHO 3 Hello20]":] [PREBOXFORTH 1 2 + . ." Hello" 4 5 * .] [P Forth reads one word at a time and executes it immediately (sometimes it "compiles" the word instead of running it, but we can ignore this now). `[TTFORTH .]' is a word that prints the number at the top of the stack, followed by a space; `[TTFORTH ."]' is a word that prints a string; it's a tricky word because it [IT interferes on the parsing] to get the string to be printed. I've always thought that this permission to interfere on the parsing was one of Forth's most powerful features, and I have always thought about how to implement something like that - maybe as an extension - on other languages.] [P So - the Forth interpreter (actually the "outer interpreter" in Forth's jargon; the "inner interpreter" is the one that executes bytecodes) reads the word `[TTFORTH ."]', and then it calls the associated code to execute it; at that point the pointer to the input text - let's call it "pos" - is after the space after the `[TTFORTH ."]', that is, at the `[TTFORTH H]'; the code for `[TTFORTH ."]' advances pos past the `[TTFORTH Hello"]' and prints the "[TTFORTHO Hello]", after that the control returns to the outer interpreter, who happilly goes on to interpret "[TTFORTH 4 5 * .]", without ever touching the '[TTFORTH Hello"]'.] [sec «Lisp» (to ".Lisp") H3 [++NN]. Lisp] [P In Lisp all data structures are built from "atoms" (numbers, strings, symbols) and "conses"; a list like [TTLISP (1 2 3)] is a cons - a pair - holding the "first element of the list", [TTLISP 1], and the "rest of the list", which is the cons that represents the list [TTLISP (2 3)]. Trees are also built from conses and atoms, and programs are trees - there is no distinction between code and data. The Lisp parser is very simple, and most of the semantics of Lisp lies in the definition of the "[TTLISP eval]" function. The main idea that I borrowed from Lisp's "[TTLISP eval]" is that of having two kinds of evaluation strategies: in] [PREBOXLISP (* (+ 1 2) (+ 3 4))] [P the "[TTLISP *]" is a "normal" function, that receives the [IT results] of [TTLISP (+ 1 2)] and [TTLISP (+ 3 4)] and returns the result of multiplying those two results; but in] [PREBOXLISP (if flag (message "yes") (message "no"))] [P the "[TTLISP if]" is a "special form", that receives its three arguments unevaluated, then evaluates the first one, "[TTLISP flag]", to decide if it is going to evaluate the second one or the third one.] [sec «.Tcl» (to "Tcl") H3 [++NN]. Tcl] [P (3) Tcl. In Tcl the main data structure is the string, and Tcl doesn't even have the distinction that Lisp has between atoms and conses - in Tcl numbers, lists, trees and program code are just strings that can be parsed in certain ways. Tcl has an evaluation strategy, given by 11 rules, that describes how to "expand", or "substitute", the parts of the program that are inside [TTTCL ""]s, [TTTCL [' []]]s, and [TTTCL {}]s (plus rules for "[TTTCL $]"s for variables, "[TTTCL #]"s for comments, and a few other things). The [TTTCL ""]-contexts and [TTTCL [' []]]-contexts can nest inside one another, and what is between [TTTCL {}]s is not expanded, except for a few backslash sequences. In a sense, what is inside [TTTCL [' []]]s is "active code", to be evaluated immediately, while what is inside [TTTCL {}]s is "passive code", to be evaluated later, if at all.] [P Here are some examples of Tcl code:] [PREBOXTCL [' set foo 2+3 set bar [expr 2+3] puts $foo=$bar ;# Prints "2+3=5" proc square {x} { expr $x*$x } puts "square 5 = [square 5]" ;# Prints "square 5 = 25" ]] [sec «TH» (to ".TH") H3 [++NN]. TH] [P Blogme descends from a "language" for generating HTML that I implemented on top of Tcl in 1999; it was called TH. The crucial feature of Tcl on which TH depended was that [IT in [TTTCL ""]-expansions the whitespace is preserved, but [TTTCL [' []]]-blocks are evaluated]. TH scripts could be as simple as this:] [PREBOXTCL [' htmlize {Title of the page} { [P A paragraph with a [HREF http://foo/bar/ link].] } ]] [P but it wasn't hard to construct slightly longer TH scripts in which a part of the "body of the page" - the second argument to htmlize - would become, say, an ASCII diagram that would be formatted as a [TTHTML [Q...]] block in the HTML output, keeping all the whitespace that it had in the script. That would be a bit hard to do in Lisp; [IT it is only trivial to implement new languages on top of Lisp when the code for programs in those new languages is made of atoms and conses]. I wanted something more free-form than that, and I couldn't do it in Lisp because the Lisp parser can't be easily changed; also, sometimes, if a portion of the source script became, say, a cons, I would like to be able to take this cons and discover from which part of the source script that cons came... in Blogme this is trivial to do, as [TTBLOGME [' []]]-blocks in the current Blogme scripts are represented simply by a number - the position in the script just after the "[TTBLOGME [<]]".] [sec «source-files» (to ".source-files") H2 [++N]. The source files] [sec «brackets.lua» (to ".brackets.lua") H3 [++NN]. brackets.lua: the parsers (_A and _B)] [# #] [sec «definers.lua» (to ".definers.lua") H3 [++NN]. definers.lua: def and DEF (_AA)] [sec «escripts.lua» (to ".escripts.lua") H3 [++NN]. escripts.lua: htmlizelines (_E)] [sec «elisp.lua» (to ".elisp.lua") H3 [++NN]. elisp.lua: makesexphtml (_EHELP, _EBASE, etc)] [sec «blogme3.lua» (to ".blogme3.lua") H3 [++NN]. dooptions (_O)] [RULE -------------------------------------------------------] [P ([STANDOUT 2007apr18]: Hey! The rest of this page refers to BlogMe2, that is obsolete... I just finished rewriting it ([Q ->] [HREF littlelangs.html#blogme3 BlogMe3]), but I haven't had the time yet to htmlize its docs...)] [P (2005sep28: I wrote this page in a hurry by htmlizing two of blogme's documentation files, README and INTERNALS, which are not very clean...)] [P See also the [HREF littlelangs.html#blogme [# -> blogme] entry about BlogMe in my page about little languages].] [# P [HLIST2 [J Quick index:] [HREF #introduction Introduction] [HREF #language How the language works] [HREF #evaluation How [QQ []]-expressions are evaluated] [HREF #def Defining new words in Lua with [QQ def]] [HREF #internals The internals of blogme2.lua] [HREF #main_tables The main tables used by the program] [HREF #tables_for_words Blogme words (the tables _W and _A)] [HREF #parsers The blogme parsers (the table _P)] [J To be written: [HREF #files files, installing, running the demos, help needed].] ]] [# ------------------------------------------------------------------ #] [sec «introduction» (to ".introduction") H2 [++N]. Introduction] [P The "language" that blogme2.lua accepts is extensible and can deal with input having a lot of explicit mark-up, like this,] [QQQ [HLIST2 Items: [HREF http://foo/bar a link] [HREF http://another/link] [IT Italic text] [BF Boldface] ] ] [P and conceivably also with input with a lot of [IT implicit] mark-up and with control structures, like these examples (which haven't been implemented yet):] [QQQ [BLOGME Tuesday, February 15, 2005 I usually write my notes in plain text files using Emacs; in these files "["s and "]"s can appear unquoted, urls appear anywhere without any special markup (like http://angg.twu.net/) and should be recognized and htmlized to links, some lines are dates or "anchors" and should be treated in special ways, the number of blank lines between paragraphs matter, in text paragraphs maybe _this markup_ should mean bold or italic, and there may be links to images that should be inlined, etc etc etc. ] [IF LOCAL==true [INCLUDE todo-list.blogme] ] ] [P BlogMe also support executing blocks of Lua code on-the-fly, like this:] [QQQ [lua: -- We can put any block of Lua code here -- as long as its "["s and "]"s are balanced. ] ] [# -- The following def [[ IMAGE 2 url,alt HREF(url, "