chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Working on format-compiler egg, question about macro


From: Alejandro Forero Cuervo
Subject: Re: [Chicken-users] Working on format-compiler egg, question about macros, eggs as wiki pages
Date: Tue, 15 Jun 2010 17:12:38 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

> From: Felix <address@hidden>
> Subject: Re: [Chicken-users] Working on format-compiler egg, question about 
> macros, eggs as wiki pages
> Date: Tue, 15 Jun 2010 15:29:30 +0200 (CEST)
> 
> > 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.
> 
> Well, expanding the complete format-string into code might lead to
> code-explosion (this isn't so much an issue for chicken's builtin
> formatting procedures, since the expansion is relatively simple).
> So you probably should ignore my previous suggestion. If you compile
> the format-string into a closure-tree you could at least cache/memoize
> it somehow, just as you wrote initially.

I believe the size of the expanded code would be proportional linearly
to the length of the format string, so I think it wouldn't be very
bad.  However, I will, still, probably take the approach of compiling
the strings at runtime, the first time they are used, and then just
caching them (forever, in the case of static strings).

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]