Separator Characters
Background
There is an issue as far as long-term consistency for the use of characters to represent logical "AND" and "OR"
This document uses CHOOSE:TEMPLATE (since it doesn't exist) as an example. For additional CHOOSE tokens and proposals, you can see Architecture Changes 5.17
To readers: Please add additional options if you have additional ideas. You may find the Data LST Standards useful to look at reserved characters.
Option #1, Using Pipe as an OR separator, Using Comma as an AND separator
Using Primitives
CHOOSE:TEMPLATE|Template1|Template2
...allows a choice of Template1 or Template2
CHOOSE:TEMPLATE|TYPE=Foo|!TYPE=Bar
...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar
...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar
Using Single a Qualifier
CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]
...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo
Using Multiple Qualifiers
CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]|QUALIFIED[TYPE=Goo]
...allows a choice of (a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar OR (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]
...allows a choice of: (a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar AND (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]|QUALIFIED,!PC
...allows a choice of: (a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo OR (b) Any Template that the PC is qualified to take, but has not yet taken.
Discussion
- Note that this is the existing syntax used in the CHOOSE proposals as they are shown on the Wiki. [TRP]
- Showing this syntax to a few non coders it definitely wasn't instinctively clear that ',' was an AND symbol. However, '|' was instinctively picked up as an OR symbol karianna 18:59, 1 April 2009 (CEST)
- Part of that is that the pipe '|' just seems to break that attention naturally, which is why it works so well as a subtoken separator. But I think we should move away from giving two jobs to the same thing.--Fluxxdog 01:12, 2 April 2009 (CEST)
Insert comments on option #1 here.
Option #2, Using Comma as an OR separator, Using Ampersand as an AND separator
Using Primitives
CHOOSE:TEMPLATE|Template1,Template2
...allows a choice of Template1 or Template2
CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar
...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|TYPE=Foo&!TYPE=Bar
...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar
Using Single a Qualifier
CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo]
...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo
Using Multiple Qualifiers
CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]
...allows a choice of (a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar OR (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]&QUALIFIED[TYPE=Goo]
...allows a choice of: (a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar AND (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo],QUALIFIED&!PC
...allows a choice of: (a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo OR (b) Any Template that the PC is qualified to take, but has not yet taken.
Discussion
- I think this is a problem, as ampersand is not a reserved character in PCGen. This is used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. Therefore, in order to implement this properly, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). While I think this is a nice idea, I think the hurdle is too large to do this quickly. [TRP]
Insert other comments on option #2 here.
Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator
Using Primitives
CHOOSE:TEMPLATE|Template1<OR>Template2
...allows a choice of Template1 or Template2
CHOOSE:TEMPLATE|TYPE=Foo<OR>!TYPE=Bar
...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|TYPE=Foo<AND>!TYPE=Bar
...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar
Using Single a Qualifier
CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]
...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo
Using Multiple Qualifiers
CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]<OR>QUALIFIED[TYPE=Goo]
...allows a choice of (a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar OR (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]<AND>QUALIFIED[TYPE=Goo]
...allows a choice of: (a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar AND (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]<OR>QUALIFIED<AND>!PC
...allows a choice of: (a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo OR (b) Any Template that the PC is qualified to take, but has not yet taken.
Discussion
- Note that the unicode discussion here was broken out into option #4. - thpr Apr 4
- I Have a similar concern here to option #2, as we have not reserved < or > as restricted characters. < and > are used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. There is less risk of using (literally) <OR> or <AND>, which makes this somewhat safer than option #2. However, this does introduce restrictions on data naming. In order to implement this without risk, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). I think the hurdle is too large to do the FREQ converter quickly. [TRP]
- Do the characters '<' and '>' matter? Are there other characters that can't be used in a key name that can be used for identifying a logical operator? What about '$'? Are there any characters that we cannot use whatsoever for this? --Fluxxdog 04:03, 1 April 2009 (CEST)
- You may find the Data LST Standards useful to find reserved characters.
- Not as helpful as you think. This just lists what should and shouldn't be used in our releases, not what actually can and can't be used. For example, we shouldn't use a backslash '\' but we can.
- DEFINE:Spaced\Variable|0 BONUS:VAR|Spaced\Variable|3 DESC:Here's the value: %1|Spaced\Variable
- ...still spits out "Here's the value: 3"--Fluxxdog 23:35, 4 April 2009 (CEST)
- [nuance] I think the lower case version stands out better.
- I'll definitely agree with nuance on using lowercase for 'and' and 'or'. Makes it so much more obvious.--Fluxxdog 01:08, 2 April 2009 (CEST)
- I happen to prefer the uppercase versions. - thpr
- One needs to consider also that these will often be used with Primitive objects, e.g.:
- CHOOSE:TEMPLATE|Extra Weaponry<or>Extra Appendage<or>Extra Flavor<or>Candle Power<or>Super Eyesight
- CHOOSE:TEMPLATE|Extra Weaponry<OR>Extra Appendage<OR>Extra Flavor<OR>Candle Power<OR>Super Eyesight
- ... so I feel that the upper case keyword is far more consistent with our tokens (where the keywords like TEMPLATE, TYPE, etc. are all upper case) and also stand out more.
- How dare you use logic! ^^ But yeah, when you put it that way, we should stick to the standard of using CAPS for hardcoded words.--Fluxxdog 23:35, 4 April 2009 (CEST)
- I happen to prefer the uppercase versions. - thpr
Insert comments on option #3 here.
Option #4, Leverage Unicode to use other separators, e.g. «OR» as an OR separator, Using «AND» as an AND separator
Examples use lowercase
Using Primitives
CHOOSE:TEMPLATE|Template1«or»Template2
...allows a choice of Template1 or Template2
CHOOSE:TEMPLATE|TYPE=Foo«or»!TYPE=Bar
...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|TYPE=Foo«and»!TYPE=Bar
...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar
Using Single a Qualifier
CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]
...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]
...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo
Using Multiple Qualifiers
CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]«or»QUALIFIED[TYPE=Goo]
...allows a choice of (a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar OR (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]«and»QUALIFIED[TYPE=Goo]
...allows a choice of: (a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar AND (b) Any Template the PC is qualified to take that is TYPE=Goo
CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]«or»QUALIFIED«and»!PC
...allows a choice of: (a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo OR (b) Any Template that the PC is qualified to take, but has not yet taken.
Discussion
- [nuance] LST files are UTF8, so theoretically we can use any unicode character. The problem with that is editor support—which it has to be said is getting better all the time. Since full unicde may be a bit of a shock , iso-8859-1 (latin 1) has « and » (alt0171 and alt0187 respectively). It also has ¿ (alt0191) which ties up nicely with ? if was want to wrap words.
- Of course, fully in the realm of unicode madness, we could always use ∧ for and, and ∨ for or, but the data folk might shoot us :-). Actually we could consider ^ to mean and, paired with |
- CHOOSE:TEMPLATE|PC[TYPE=Foo^!TYPE=Bar|TYPE=Goo]|QUALIFIED^!PC
- ...allows a choice of:
- (a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
- OR
- (b) Any Template that the PC is qualified to take, but has not yet taken.
- I think I prefer the last one, but I don't like the way | looks against ]. On this wiki ! is hard to distinguish from |, ¬ (shift ` on my keyboard) actually means not. I think using « and » in place of [ and ], and ¬ for not
- CHOOSE:TEMPLATE|PC«TYPE=Foo^¬TYPE=Bar|TYPE=Goo»|QUALIFIED^¬PC
- is easier to read but that might be a bit radical. Perhaps it's time we has that full reserved characters discussion.
- I'd like to move away from symbolism for words and actually use the words themselves. It makes it a lot easier for new people to read.--Fluxxdog 01:08, 2 April 2009 (CEST)
- Using '«' and '»' is a good idea, but how exactly do you type that in? I think we should stick closer to what's available on the common keyboards without having to dig through a font list. Although, that gives me an idea... What about a character combinations?
- nuance Sorry if it was a bit opaque, but I gave instructions for how to type it (on a windows machine at least). Press and hold the "alt" key to the left of your space bar. Now, using the numeric keypad, type the numbers 0171, realease the "alt" key. Et viola «. » is similarly produced with the numbers 0187. Once you have one of them cut and paste is also an option. Since we aren't fully in the unicode realm here, most OSes have some way to type characters in the ios-8859-1 range.
- Hey coders! Could we do something along the lines of <<and>>? Using 2 '<' to signify a logical operator? Surely that must make things easier. -Fluxxdog 01:08, 2 April 2009 (CEST)
- Really doesn't make a huge difference. The < and > still aren't identified as reserved characters. It reduces the risk slightly, but it's probably small with <AND> and <OR> anyway. - thpr
Insert comments on option #4 here.