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

[Julien Fischer]

On Sun, 16 Nov 2014, Zoltan Somogyi wrote:

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

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

There are three possibilities:

io.m: it's true that the instances in this module are the only instances
*in the standard library* that uses the types in question.  However,
there's no reason I cannot read Mercury strings (and lines and
text_files) from other streams that have nothing to do with the io
module (e.g. a memory buffer attached to a store).

stream.m: this module is supposed to define only the interface to
streams, not the details of their instances.  Also, line_oriented
streams are not restricted to Mercury strings (and their views).  They
are potentially usable with any stream that has a string-like unit and
also has a notion of lines.

string.m: IMO this is where they belong, if only because I expect to
find string related stuff in the standard library module named 'string' 
and they don't seem to belong in the other two modules.

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

The downside to that is the only way for me to change the behaviour is
to go and edit those pragmas.  I'm not sure at what number of
foreign_decl pragmas that becomes as annoying as having to hunt for the
option in the user guide.

Cheers,
Julien.