[m-rev.] diff: string splitting routines to string.m

[Ralph Becket]

Ondrej Bojar, Friday,  2 February 2007:
> Ralph Becket wrote:
> >We already have the pred string.remove_suffix.  I would rather you added
> >a function version of string.remove_suffix (`chomp' isn't a good name,
> >even if it's used in millions of Perl scripts).
> 
> remove_suffix_if_present would be better?
> or
> remove_suffix_det  -- I don't like this one
> or
> chomp_suffix
> 
> I just think it needs to be different from remove_suffix (semidet), but 
> the name should not suggest raising an exception (as _det functions tend 
> to do).

I think remove_suffix alone is okay, but I take your point and would be
happy with remove_suffix_if_present.

> >>+:- func string.split_at_separator(pred(char), string) = list(string).
> >>+:- mode string.split_at_separator(pred(in) is semidet, in) = out is det.
> >Is this generally useful enough to go in the string module?  (I have no
> >idea one way or the other.)
> 
> You have string.words_separator, which is unfortunately absolutely 
> useless for tab-delimited input lines, because it removes consecutive 
> tabs... split_at_{char,separator} fix that.

Okay, that's a good argument.

> >>+    % string.split_at_string("|||", "|||fld2|||fld3")
> >>+    %  = ["", "fld2", [fld3"]
> >What does string.split_at_string("aaa", "xaaaa aaaaax aaa x" return?
> 
> ["x", "a ", "aax ", " x"]
> 
> Proposed comment:
>   Always the first match of Separator is used to break the String, for 
> example:
>   string.split_at_string("aa", "xaaayaaaz") = ["x", "ay", "az"]
> 
> >Is this useful enough to go in string.m?
> 
> Depends on the type of input you tend to process often.
> 
> I don't know your general policy. My policy would be: given any 
> super-nifty function (with a testcase provided), if a reasonable number 
> of programmers agree on the module it should go in and they understand 
> well what it does given the name it should get, I'd put it in and not 
> ask how often will they use it.

Extending modules means extra maintenance and makes it harder
for users to find the genuinely useful parts, which is why we
adopt a conservative approach to adding new functionality.  Code
whose universal utility we're unsure about tends to go in extras.
In this case I'm just looking for a convincing case *for*
split_at_string, but I'm not arguing *against* it.

> >In general you should adhere to the coding style used in the module you
> >are editing.
> 
> I was already trying to :-( But I'll fix all other places you mentioned 
> or I can find.

Ta!
-- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------