Just wanted to comment officially on this, since the question has come up.
A FORMAT function has been intended as part of REBOL/Core all along (which is why I
elected to call FORM FORMAT. I have reserved the word FORMAT for the full function.)
FORMAT is conceptually the inverse of PARSE, and like PARSE, would accept a dialect to
provide the formatting rules (including defining subrules, repeats, variables, etc.)
Unfortunately, I've been too busy to pursue FORMAT. It takes a lot of thought. It
was great to see Eric come up with something that would fill the need. A lot of users
want this, and Eric has got working.
Will FORMAT be part of REBOL in the future? Yes, that's the plan. Formatting
features do need to be part of REBOL, both in a FORMAT function and as refinements to
FORM. I cannot promise that they'll look or work like Eric's, but they will become a
standard part of the language in the future. When? Can't say.
-Carl Sassenrath
REBOL Architect
PS: Eric, good job! One suggestion: use # instead of % for your spec string. The %
is for filenames, as some of us write filters that scan source code for filenames,
looking for the % format. Also, a question: can the N.M format spec be used reliably,
because decimal rounding errors could occur, and the M may not return to the same
integer?
At 2/6/00 01:33 AM -0800, you wrote:
> <[EMAIL PROTECTED]> schrieb am Sun, 6 Feb 2000 16:31:37 +0900 �ber
>"[REBOL] New format.r on rebol.org" in <[EMAIL PROTECTED]>:
>
>> The main reason for writing FORMAT (the main function in format.r) was the
>> lack of any control over how numbers are formed in REBOL. There are at least
>> three problems here that format.r solves:
>
>IMHO at least some of this functionality should actually go into
>REBOL/Core in some time.
>
>--
>Martin 'Helios' Steigerwald - http://helios.home.pages.de
>PGP: http://home.pages.de/~helios/autor/wie-erreichen.html
>ICQ: #34355756
>
