Ethy H. Brito ethy.brito at inexo.com.br
Fri Jan 26 11:59:16 EST 2007

```On Thu, 25 Jan 2007 10:00:54 -0500
Derek Atkins <warlord at MIT.EDU> wrote:

> >> Are you offering to code this and send in a patch?  :-D
> >>
> >
> > yes I am. In fact I am working on the idea reading the code to catch your
> > programing style and propose something that fits in.
>
> Cool!  I look forward to your patch.  :)

Here go my thoughts:

I think the "problem" has to be dealed at check number increment/decrement.
If this is done correctly, the import matching do not have to be smart
(a simple str[n]cmp will do the job as it is today)
Please correct me. I have no deep knowledge of GC innards.

Then I thought about a print function.
It may deal with some format string and parse whatever the user writes, formatting accordingly something like this:

1- print numbers against a (C like) pattern

c - alfabetic chars from A to Z
h - alfabetic chars from 0 to 9 and from A to F
d - alfabetic chars from 0 to 9
u - a user defined ASCII sequence (in any order) up to 36 chars

As examples printing decimal number 123 under the format string:
"dddddd"       -> 000123
"dddcdddddd"   -> 000A000123 (also number 123. "A" is equiv. to 0)

In this last example we have three groups:
the first with 3 digits
the secont: a single alphabetic char
the third: 6 digits

2-    Each group of identical type will be inc/decremented separately
adding the carry bit from the group at its left

For instance the format string "ddd ccddd" will give us
"000 ZZ999" + 1 = "001 AA000"
(just for fun: don't have any ideia what "000 ZZ999" decimal number is)

3-    Some flags may controls when strip leading zeroes from target or
to honor the carry from previous operations.

4-    Overflows/wrapping are governed by each field length

Too complex? Any hard impacts on GC as it is now?