Mercury Bugs - mercury
View Issue Details
0000096mercuryBugpublic2009-05-28 12:142010-01-27 17:06
Reporterpbone 
Assigned Torafe 
PrioritynormalSeveritytextReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000096: some predicates parsing_utils are documented with arguments in an incorrect order.
Description
Some documentation comments in parsing_utils don't match the actual order of the aguments of the predicate.
Additional Information
For example:

    % keyword(Src, IdChars, Keyword, _, !PS) matches Keyword exactly (i.e., it
    % must not be followed by any character in IdChars) and any subsequent
    % whitespace.
    %
  :- pred keyword(string::in, string::in, src::in, unit::out,
       ps::in, ps::out) is semidet.

Above the src argument has the third place in the type declaration (which is correct making this easy to use as a curried higher order argument to other predicates), while the documentation places this argument in the first place.
TagsNo tags attached.
Attached Files

Notes
(0000167)
pbone   
2009-05-28 12:21   
It seems that the set module has the same problem.
(0000168)
juliensf   
2009-06-01 18:43   
For the sake of uniformity in the parsing_utils module it would be better if the
Src argument was always first (when present) -- that's what half of the predicates
in the interface of that module do anyway.

Which predicates in the set module had inconsistent documentation? I looked but
couldn't see any.
(0000170)
pbone   
2009-06-02 17:00   
Julien:

When accepting more than the four arguments (src::in, T::out, ps::in, ps::out) a predicate must put the extra arguments before the source argument. Many predicates in this module take a higher order argument with these four arguments that is semidet. Predicates who's argument lists end in exactly these four arguments can be easily curried to create higher order arguments.
(0000171)
pbone   
2009-06-02 17:14   
Disregard my comments about the set module with regard to this bug.
(0000248)
juliensf   
2010-01-27 17:06   
Fix committed, see r1.5 of library/parsing_utils.m.

Issue History
2009-05-28 12:14pboneNew Issue
2009-05-28 12:21pboneNote Added: 0000167
2009-06-01 18:43juliensfNote Added: 0000168
2009-06-01 19:01juliensfStatusnew => assigned
2009-06-01 19:01juliensfAssigned To => rafe
2009-06-02 17:00pboneNote Added: 0000170
2009-06-02 17:14pboneNote Added: 0000171
2010-01-27 17:06juliensfNote Added: 0000248
2010-01-27 17:06juliensfStatusassigned => resolved
2010-01-27 17:06juliensfResolutionopen => fixed