2024-07-13 14:08 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000096mercuryBugpublic2010-01-27 17:06
Assigned Torafe 
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




pbone (administrator)

It seems that the set module has the same problem.


juliensf (administrator)

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.


pbone (administrator)


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.


pbone (administrator)

Disregard my comments about the set module with regard to this bug.


juliensf (administrator)

Fix committed, see r1.5 of library/parsing_utils.m.

-Issue History
Date Modified Username Field Change
2009-05-28 12:14 pbone New Issue
2009-05-28 12:21 pbone Note Added: 0000167
2009-06-01 18:43 juliensf Note Added: 0000168
2009-06-01 19:01 juliensf Status new => assigned
2009-06-01 19:01 juliensf Assigned To => rafe
2009-06-02 17:00 pbone Note Added: 0000170
2009-06-02 17:14 pbone Note Added: 0000171
2010-01-27 17:06 juliensf Note Added: 0000248
2010-01-27 17:06 juliensf Status assigned => resolved
2010-01-27 17:06 juliensf Resolution open => fixed
+Issue History