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

[Zoltan Somogyi]

On Sun, 16 Nov 2014 19:16:54 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > 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.)

I think so too, but wanted to be sure, which is why I asked the question.

> > 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.

Yes, I did.

> 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.

They are not used by the string module, and represent a semantic
view imposed on strings by some other entity. Nothing in string.m itself
uses this view.

From what you say, maybe they should go into io.m, next to the
instance declarations that use them.

> > 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.

At the moment, foreign_decl pragmas have an optional second argument,
which may only be "local". I was thinking of allowing this second arg
to also be something else, which says "not local, but don't generate #line
directives for me". That wouldn't be *that* much harder to implement,
would give a finer grain of control, and wouldn't require users who get
a C compiler error to hunt in the user guide for the name of the option
to turn on #line directives in .mh files.

Zoltan.