>> 3 - each word oriented, builtin function will have an extra parameter that
>> can be used to override the implementation default.
>
>Many of these functions already have a bunch of optional parameters. We're
>talking about ending up with things like FUNCTION(A,B,,,'20090D0A'x) with each
>function having a different amount of commas, not to mention the hassle of
>typing the list of delimiters every time.
>
I agree that more parameters are a pain. But I think that this capability would
be very useful for lots of things, not just handling what Uni* call whitespace
and VM don't. This would be an optional parameter, you'd get the default
otherwise, which probably would be ok as long as you agreed with the implementor's
idea of what are good delimiters. And you could change the default characters
with a ONE TIME call to, Options blah delimiters, OR with a bif, as was
suggested by Dave Gomberg, setdelimit(...).
I think the whole problem reduces to, either define some kind of program
control for this, or hang it on the implementor's shoulders and hope you like
what he/she decides (there's no way you can standardize a set of whitespace
characters).
>> 4 - logical comparisons will use the implementation default delimiters to
>> fudge the ends of strings. Unless the strict comparator operators are
>> used.
>
>Which gives you an incomplete/inconsistent tools - for some things you can
>define your delimiters, for others you can. Not very convenient I'm afraid.
>
> Eric
You CAN define them for everything (did I miss a spot?). You can set "global"
delimiters. Or override them in builtins. Not very elegant, I agree. But
I think it would be a good thing to think of delimiters as just another
string handling concern, along the level of the pad char that some functions use.
I don't think we should make this harder than it is. The thing that's futsy, fudgy, icky, is the what constitutes a legal leading/trailing don't care char.
