[Top][All Lists]

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


reply via email to

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