[m-rev.] for review: carve four modules out of term.m

[Zoltan Somogyi]

2022-08-20 15:44 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
>> can get access to contexts without importing term.m
>> This could be done by moving the type, and its operations,
>> to a new module in the library, with an equivalence type
>> as well as forwarding predicates left behind in term.m.
> 
> We have certainly discussed the possibility of moving the context type
> to its own module before -- although, I could not find where on the
> mailing list. From memory, there are quite large number of modules in
> the compiler that are only importing the term module solely to get
> access to the context type.

Yes, that is exactly my motivation for that proposal.
 
>> Or it could be by adding a type functionally equivalent
>> to term.context to the HLDS, and having the code
>> that adds parse tree components to the HLDS convert
>> contexts to this new type. The former approach is simpler,
>> while the second is more flexible, in that it would allow us
>> in the future to replace our current contexts, which always
>> refer to a single line, with contexts that refer to a range
>> of line numbers.
>> On the other hand, adding column number info as well, e.g. to enable
>> highlighting of just the characters of an erroneous term, would
>> require changes in standard library modules anyway.
>>
>> Opinions?
> 
> As a starting point, I would move context to its own module, e.g.
> term_context.

Will do.

> Perhaps we can just mark this as obsolete?

Done.

>> +:- pred decimal_term_to_int(term(T)::in, int::out) is semidet.
>> +% XXX NOTE_TO_IMPLEMENTORS Why no versions for sized and/or unsigned ints?
> 
> decimal_term_to_int/2 is used within the compiler when processing terms
> containing numbers (e.g. arities in instance or pragma decls). All of
> those places only require decimal ints and do not use the other integer
> types (i.e. there's never been any need to have similar operation for
> other types.)

I added a note about that, but the left the note about the lack of
orthogonality.

> IIRC, before the other integer types were added the code in the compiler
> was actually incorrect and would have allowed, e.g. hexadecimal arities,
> when it was parsing terms that referred to arities.  the change to the
> term module's representation of integers made this show up a bit more
> obviously, which was why decimal_term_to_int was added.
> 
> The diff looks fine.

Thank you.

I will commit this with NEWS entries; I will look at the extras and samples
separately.

Zoltan.