[m-dev.] some issues I noticed while working on string.m

[Julien Fischer]

On Sun, 16 Nov 2014, Zoltan Somogyi wrote:

> While reordering the contents of string.m, I noticed some
> things that I would like your opinions on.

...

> Thing 3
>
> The MR_set_code_unit function was added (as MR_set_char) by Fergus
> exactly 14 years ago, on 16 nov 2000. For speed, I want to remove
> the workaround that this function represents. Who has the oldest
> gcc version installed on their machine? If that doesn't need
> this workaround, then I think we can safely delete it. On my
> machine, it is gcc 4.6.

I will try it with older versions of GCC and let you know how it goes.
(I'm fairly sure that workaround, and indeed any others related to
egcs could be removed now.)

> Thing 4
>
> Do the types line and text_file really belong in string.m? To me,
> they seem to belong more in string.m, next to the comment that
> says "Line oriented streams". Any opinions?

I assume you mean stream.m rather than string.m the second time.  That
isn't the right place IMO.  The instances that use those types are in
the io module.  The types are needed so that we can support separate
readers for text files, lines and arbitrary strings.  Since both types
represent kinds of string I see no problem with them being defined in
the string module.

> Thing 5
>
> At the moment, when a .m file contains a foreign_decl pragma,
> we write that out the contents of that pragma with a #line directive, like this:
>
>    #line 1296 "string.m"
>
>    #include <ctype.h>
>    #include <string.h>
>    #include <stdio.h>
>
>    #include "mercury_string.h"   /* for MR_allocate_aligned_string*() etc. */
>    #include "mercury_tags.h"     /* for MR_list_cons*() */
>
> The #line directive is nice for users if the foreign code declaration
> has a problem, but when the position of the foreign_decl in its source file
> changes, the resulting change in the #line directive causes the recompilation
> of every .c file that includes that .mh file, even when those recompilations
> are otherwise unnecessary.
>
> We can avoid those unnecessary recompilations by either
>
> - adding an option to foreign_decl directives that allows users to tell the
>  compiler that it can leave out the #line directive, probably because
>  the foreign code is unlikely to yield error messages; or
> - we can simply never write out #line directives in such cases, figuring
>  that this is true for a large majority of the things people put in
>  foreign_decl pragmas.

I have found writing out the #line directives to be useful when writing
bindings to C libraries.  I have no objections to adding a command line
option to control this and not enabling it by default.

Cheers,
Julien.