(mac blogpage (title . body)
`(do (prn "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">")
(tag html
...
Additionally, I'd like to see the link macro replaced by something that doesn't... uh, conflict with the <link> tag (which is forcing us to use ugly (pr)s right now instead of (tag)).
(attribute link type opstring)
(attribute link href opstring)
(attribute link rel opstring)
(gentag type "text/css" rel "stylesheet" href "styles.css")
While the doctype would sort them out usually, it seems that (defop index.css ...) is serving up the page oddly now, such that the CSS isn't being applied.
It's a clever hack but I'm not crazy about the inline CSS and JS in news.arc. I would just serve static files and as a bonus you'll get all the benefits of the CSS and JS modes of your text editor while editing the stuff. Perhaps pg just wanted to keep the arc dir tidy and doesn't actually do that on news.yc.
To make this work for functions, you need to add ((procedure? s) s) to 'ac. Otherwise with arc2.tar:
arc> (mac dont-break (a b) `(,list ,a ,b))
#3(tagged mac #<procedure>)
arc> (let list nil (dont-break 1 2))
Error: "Bad object in expression #<procedure: list>"
Macros still remain a problem:
(mac list-macro parms `(,list ,@parms))
(mac break (a b) `(,list-macro ,a ,b))
(break 1 2) => Error
The <div ... </div> is written to stdout; it's a side-effect, not the result of the expression. It is the trailing "</" that's the result of the expression, and therefore gets written to stdout after the expression's side-effects.
I don't think 'tag means to return "</" in particular. It's just that 'pr -- which is used to write the closing tag like so: (pr "</" ...) -- returns its first argument and 'tag returns the value that's returnd by 'pr.
It seems too that special end-of-symbol handling in the core, just because some users might possibly want to use intrasymbol-notation characters at the end of function names, does not go well with Arc's design philosophy:
... avoid having a language designed according to arbitrary rules rather than the actual demands of the task ...
I don't think intrasymbol notation should necessarily keep one from using special intrasymbol characters at the end of function names, even though currently it does.
I'm not exactly sure if this is what you want. I believe there is a difference between macros that are only expanded once (in lazy compilation), and macros that are called each time the macro-expression is encountered. Though the latter case would only make sense if the macro exhibits side-effects, or depends on side-effects, or if the argument list to the macro may change. Not sure whether there is any benefit in that.