Re: [Chicken-users] Working on format-compiler egg, question about macros, eggs as wiki pages

[Felix]

From: Alejandro Forero Cuervo <address@hidden>
Subject: [Chicken-users] Working on format-compiler egg, question about macros, 
eggs as wiki pages
Date: Sun, 13 Jun 2010 22:36:25 +0200

> As part of my migration from Chicken 3 to Chicken 4 I'm rewritting the
> format-modular egg into what I'm calling 'format-compiler'.  I'm
> reverting many changes from it and I'm cleaning up some of the
> interfaces, to hopefully make it easier to extend (ie. to define
> control characters that do interesting things).  I'm also fixing some
> bugs I've found and removing a lot of unnecessary complexity that has
> been gradually added to it with little purpose.  I have a draft of
> this code here:
> 
>     http://azul.freaks-unidos.net/format-compiler

Very good! A solid implementation of CL-style formatting is dearly
needed, since the `format' egg is buggy and the basic `[sf]printf'
stuff is not particularly powerful. There is Shinn's formidable `fmt',
which I like to get used to (but haven't used it intensively enough).
In the end I always use `print' and `display' and normally that's
enough.

The complexity of the current `format-modular' code isn't so much the
problem - the large number of dependencies is. It would be good to
remove i18n support and for example provide hooks or another sort of
interface to extend it in a clean manner without increasing the size
and the number of base-dependencies of a bread-and-butter extension
like formatted text output.

> 
> I'm doing a pretty large change to it: I'm separating the process of
> parsing the format string rom the process of actually generating the
> output.  My thinking is that most of the time format strings are
> specified statically and never change during the execution of a
> program, as in:
> 
>   (format (current-error-port) "Evaluating ~A form: ~A~%" adj name)
> 
> Instead of parsing the string every time, I want to parse it once and
> then use the result of that parsing on the arguments passed.

Cool - this reminds me of Common Lisp's `formatter' macro. By
seperating the format-compiler into a module, it would be possible
to use it at compile time and provide a similar facility by using
compiler-syntax.

> 
> Interestingly, this is actually allowing me to simplify the
> implementation significantly (or maybe I'm a slightly better
> programmer now than I was when I wrote format-modular?).

Well, I don't know about now, but I always envied the clean
coding style you use. :-)

> The catch is, of course, that one may memoize fmt-compiler —perhaps
> using “eq?” on the format string (for which I'll probably extend the
> memoize egg)— which means that a given statically specified format
> string would be parsed at most once and the results of that parsing
> reused through-out.
> 
> In order to make this happen, I figured I would ask: is there a way
> for, in a macro, check if a given symbol is actually a hard-coded (ie.
> static) string?  In other words, if my macro is called “format”, I
> would like “(format x "static" ...)” and “(format x foo ...)” to have
> different expansions, where the expansion for the former caches the
> results of the parsing forever and the expansion of the later only
> caches them for some time, with some heuristics.  Is this possible at
> all?

Sure: 

(define-syntax (a-string? x r c) (string? (cadr x)))

(a-string? "abc")  ~~ expands to ~~>   #t

To allow using `format' like a nomrmal function (if in non-operator
position), I recommend using compiler-syntax
(`define-compiler-syntax') for `format' and the mentioned separate
module that allows using the format-compiler at
compile-time. Exporting compiler-syntax cleanly from a module is a bit
tricky, though - I will try to figure this out.

> 
> I will add this code as an egg for both Chicken 3 and Chicken 4 once
> it's ready.  I still have to add support for a few control characters.

Great!

> 
> This is also interesting for me in that it is an experiment of storing
> an egg entirely in a wiki page.  For example, the page has the
> following tag:
> 
>   <schemelibrarydefinition
>     author="Alejandro Forero Cuervo"
>     authoremail="address@hidden"
>     category="io"
>     synopsis="Creates format procedures to generate output based on format 
> strings."
>     license="Public Domain"
>     name="format-compiler"
>     uses="posix embedded-test"
>     exports="*formatter-params* ..."/>
> 
> This is enough for Svnwiki to generate the setup, meta and Scheme
> source code files (with the blocks embedded in the wiki page) for me
> to just copy into the eggs repository.  In that sense, the wiki page
> itself becomes the authoritative location for the egg.  See, for
> example:
> 
>     
> http://wiki.freaks-unidos.net/weblogs/azul/xsvnwiki-enscript/format-compiler/format-compiler.scm
>     
> http://wiki.freaks-unidos.net/weblogs/azul/xsvnwiki-enscript/format-compiler/format-compiler.meta
>     
> http://wiki.freaks-unidos.net/weblogs/azul/xsvnwiki-enscript/format-compiler/format-compiler.setup
> 

So this is effectively like a literate programming tool? An
interesting idea.


cheers,
felix