Peter Bortas @ Pike developers forum wrote:

It's so quirky that we might want to consider a warning for that.

What about this:

(string)({65,66,"abc",67,"def",68})

Can we turn it into: "ABabcCdefD" ? Currently this doesn't work (obviously). The reason I would like to have this is that in order to parse strings and accumulate results, in Pike I tend to either pick the characters apart as integers, or use strings of characters whenever the parsing allows me to go faster.

The result is that I would like to accumulate the results piecemeal in an array. This array gets filled like in the example above. Then I'd like to return a single string to the function caller, in which case I could cast it to string (as done above).

From a language purity standpoint I realise that implementing the cast like

this is not quite proper. Then again, I can't think of any other reasonable result the cast should have (except throw an error). Thus in essence it's a DWIM (Do What I Mean) behaviour and conforms to the principle of least surprise.

Comments?

Per Hedbor () @ Pike (-) developers forum wrote:

How about having a specific function for that instead of (string)?

From a performance standpoint, that shouldn't be a problem.

Any suggestions as to the name of the function?

I'd say something like:

gather(({"abc",({65,65,66}),"def",65})) => "abcAABdefB"

The original magic '*' operator can be implemented using

array magic = ({"abc",({65,65,66}),"def"});

((array(string))magic)*"x"

Yes, but that kills performance, since it creates a (at least one) temporary string (per subarray) in the process.

without special code in '*', btw.

If gather() (as above) is allowed in, then I can take out the changes to "*" (except perhaps the tighter error checks which seem prudent).

Marc Dirix wrote:

...

gather(({"abc",({65,65,66}),"def",65})) => "abcAABdefB"

Maybe a more general "to_string()", which is IIRC also the naming inside some modules to output contents to stringform?

Well, actually, that would be confusing, since a generic array_to_string() or to_string() raises the question why it isn't equivalent to a mere cast to string, which would be the "natural" way of doing this. So in order to set it apart from the mere cast, the name should be more than a mere "to_string".

Mirar @ Pike developers forum wrote:

String.collect String.gather

maybe? (I haven't checked if they are in use.)

There already exists String.int2char(), maybe expand it to enable eating array(int|string) ?

Mirar @ Pike developers forum wrote:

String.collect String.gather

maybe? (I haven't checked if they are in use.)

I'd have a slight preference for String.gather then. Any other votes?

Peter Bortas @ Pike developers forum wrote:

-2

I gather (pun intended) that is a strong no vote, any alternate ideas on how to implement the desired functionality? Or preferably no implementation at all?

The reason I would like to have this is that in order to parse strings and accumulate results, in Pike I tend to either pick the characters apart as integers, or use strings of characters whenever the parsing allows me to go faster.

Hmm, I almost never pick strings apart into individual characters since I believe it's slow (although I really haven't measured). I usually manage to do it in ways where the individual char picking is kept at the C level (sscanf ftw).

The result is that I would like to accumulate the results piecemeal in an array. This array gets filled like in the example above. Then I'd like to return a single string to the function caller, in which case I could cast it to string (as done above).

And you can't use String.Buffer for it? It has add() for strings and putchar() for chars.

When parsing structures which can extend over newlines and/or support wierd quoting rules (like csv), it's almost inevitable.

When I need to parse, say, backslash escapes (and sscanf's %O doesn't do the right thing), I start by splitting on \ and then investigate the pieces. Or alternatively I use sscanf in more or less the same way, i.e. scans data up to a character, do stuff with it, then loop. E.g:

String.Buffer out = String.Buffer(); while (1) { int res = sscanf (in, "%[^\]\%c%s", string pre, int esc, in); out->add (pre); if (res != 3) break; switch (esc) { case '\n': case '"': out->putchar (esc); break; // ... } }

I almost always use tricks like that to avoid single stepping chars on the pike level. Even though the loop above actually is O(n^2) I believe it's faster on moderately small strings.

But then again, I also got integer chars in my example above, so maybe we're talking about the same approach afterall.

I know, that's why it's O(n^2). As I said, even so.. But if the input is long then an approach using splitting ought to be used instead.

It'd be nice to have something like String.Buffer for parsing too. Maybe it could be extended with functions like get_char, has_prefix, get_prefix, sscanf, etc.

Same as %4711s, but doesn't write it down in the argument list.

It's a pity you'd have to put "4711" in your format string though...