> > 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/ _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
