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

[Alejandro Forero Cuervo]

> > 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.

Yes!  I have removed i18n support from it, something that I think
should never have been added to it.  It had been added to output
numbers in different languages, but this was clearly broken: I wrote a
bit about it here:

  http://wiki.freaks-unidos.net/weblogs/azul/format-compiler#english-output

I want to come up with an interface for people to define other
format-compiler-* eggs that extend the functionality of the default
format function provided by format-compiler if they are installed
(akin to how the svnwiki extensions (since I completely redefined the
interface for extensions), if installed (and enabled), extend the
logic of different hooks in svnwiki).

> > 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. :-)

Thanks, Felix!

> > 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 read about this.  I'm still a bit confused about the semantics
for macros in Chicken 3 and Chicken 4.  Hopefully I'll be able to
figure out how it works.  May I abuse you by asking you what the
canonical location for the documentation about macros in Chicken 4 is?

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

That's exactly what it is.  I like literate programming.  This is my
attempt to create a framework for development of Scheme code combining
some principles from literate programming, wikis as a collaborative
medium and unit testing (the tests are embedded there in the wiki
page, actually).  I have some tools to assist this apart from the
logic directly in Svnwiki.

Thanks for your feedback!

Alejo.
http://azul.freaks-unidos.net/