Mercury Bugs - mercury
View Issue Details
0000096mercuryBugpublic2009-05-28 12:142010-01-27 17:06
Assigned Torafe 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000096: some predicates parsing_utils are documented with arguments in an incorrect order.
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

2009-05-28 12:21   
It seems that the set module has the same problem.
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.
2009-06-02 17:00   

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.
2009-06-02 17:14   
Disregard my comments about the set module with regard to this bug.
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