[m-rev.] for review: replace four "safe num digits" tables with one

[Julien Fischer]

On Tue, 15 Sept 2026 at 20:33, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> For review by Julien. I used an awk script to merge the four old tables
> into the new table, so you don't need to check every entry in it.

My only suggestion is that you have one table for each word size, as
the compiler
should be able to eliminate the unneeded table entirely.

> Unless you object, I also intend to move all the get_num_X_digits_in_Y
> and fill_string_with_X macros from the foreign_decl block at the start
> of the implementation section into a new file in the runtime, and
> replace them a #include of that new file.

What's the benefit of putting them in the runtime? The only users of
those macros
are in the string module, and under your proposal below would be moved to
string.from_builtin or string.to_builtin anyway.

> I also intend to move the implementations of the builtin_type_to_string
> and string_to_builtin_type kinds of predicates (including the string to int
> predicates) to new submodules of string.m, named maybe string.from_builtin
> and string.to_builtin.

My suggestion is:

* Leave the character conversions where they are.
* Move all of integer type conversion to string.from_int_type and
string.to_int_type.
* Move all of the float type conversions to string.from_float_type and
string.to_float_type

The reason I would make this split is that we haven't really addressed
conversion to / from floats in any meaningful way -- the C grades currently rely
on sprintf and sscanf -- but it is likely we shall do so one day and when
that occurs there will be rather more code for the float conversions present.

> (string.to_string is already taken.)

It's a private submodule and could be untaken, although I think its current
name is fine.

> The objective of all this is to reduce the size of string.m (which is now
> the largest library module by far)  and keep it manageable.

The same though occurred to me the other day when I was working on it,
so no objection from me.

Julien.







>
> Zoltan._______________________________________________
> reviews mailing list
> reviews at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/reviews