Re: [Gnucap-devel] parameter case sensitivity

[Felix Salfelder]

Hi Al.

On Sun, Nov 06, 2016 at 12:55:02PM -0500, al davis wrote:
> I am thinking a new kind of character .. call it "Ichar".  It's just
> like a "char" except for the compare functions.
> [..]
> // with a case-sensitivity switch
> bool less(a,b){
>       return (!OPT::case_insensitive && tolower(a)==tolower(b))
>               ? a<b : tolower(a)<tolower(b); }
>
> Now use it everywhere.
>
> Once that is done, all those "if (insensitive)" can be stripped.

this looks equivalent to what i did, except it's more elegant.

> We need to think of "what-if's" regarding switching modes, to make sure
> it makes sense.
> 
> The issues:
> 
> 1. Parameter is defined case-sensitive, then used insensitive.
>       This one seems easy at first, but what about duplicates?

tell about duplicates via error()? this will not be possible with IChar
and less alone. my current approach uses a DICT class to wrap the map,
would that be a good place?

> 2. Parameter is defined insensitive, then used sensitive.
>       Does storage preserve case?
>       Does it become sensitive after initial storage?
>       or does this word become insensitive forever?

interesting thought. "sensitive after initial storage" is what the
proposed solutions do.

an alternative "insensitive forever" might look like

hypothetical gnucap> insensitive on
hypothetical gnucap> parameter answeR=42
hypothetical gnucap> insensitive off
hypothetical gnucap> eval Answer
Answer=42 // !!

i have no clue how to do that (efficiently, elegantly etc.). and it
might get confusing here

hypothetical gnucap> parameter AnsweR=43
hypothetical gnucap> eval answeR
...

there are reasons for both, 42 and 43. but do you see a use case?

my uneducated preference is "sensitive after initial storage", without
extra tolower or toupper in insensitive mode. FTR it will produce

hypothetical gnucap> insensitive on
hypothetical gnucap> parameter answeR=42
hypothetical gnucap> insensitive off
hypothetical gnucap> eval Answer
Answer=Answer // it's not there, (no surprise)

> 3. Remember, it's not just parameters.

indeed, i have DICT under parameters, under the dispatcher and for
nodemaps in the draft i pushed earlier today. there's more i could use
it for (e.g. insensitive madness in gnucap-adms parameters...).

thanks!
felix