Separator Characters - Revision history

LegacyKing: /* Discussion */

2009-05-01T21:41:12Z

‎Discussion

Tom Parker: /* Discussion */

2009-05-01T18:54:41Z

‎Discussion

LegacyKing: /* Discussion */

2009-05-01T08:30:40Z

‎Discussion

LegacyKing: /* Discussion */

2009-05-01T08:28:32Z

‎Discussion

Michael W. Fender: /* Discussion */

2009-04-09T00:50:00Z

‎Discussion

Michael W. Fender: /* Discussion */

2009-04-09T00:42:50Z

‎Discussion

Nuance at 21:55, 8 April 2009

2009-04-08T21:55:53Z

Michael W. Fender: /* Discussion */

2009-04-06T00:26:14Z

‎Discussion

Tom Parker: /* Discussion */

2009-04-05T23:52:00Z

‎Discussion

Michael W. Fender: /* Discussion */

2009-04-05T23:14:00Z

‎Discussion

@@ Line 73: / Line 73: @@
 ** This would grant the choice of something with both the types Foo and Bar, or Bread or Water. Seems more intuitive that way. It also follows existing ADD syntax. ADD:ABILITY|AUTOMATIC|Foo,Bar,TYPE=Fun < See the PIPE delimits the Main Syntax Purpose:Token|Subtoken|Choice,Choice. [AM 5.1.09 @ 1:27 PDT]
 *** Let me clarify, because the description above leads to some questions. Currently one can do: TYPE=Foo.Bar,Bread,Water in many different tokens.  Are you implying that syntax should break in the new CHOOSE and one should be required to do: TYPE=Foo.TYPE=Bar,Bread,Water? [TRP]
 **** If so, to require TYPE= after each . triggers inconsistencies with many other LST tokens and would drive a separate code path.  This may be okay, and perhaps beneficial since it allows the use of . as AND, but two things:  [TRP]
 ****# There could be (is likely to be?) confusion as to coding syntax [TRP]
 ****# for backwards compatibility reasons, CHOOSE could no longer be used as the token name.  Otherwise, TYPE=Foo.Bar changed definition from "any object that is TYPE=Foo and TYPE=Bar" to "the primitive Bar if and only if it's TYPE=Foo".  [TRP]
 *** Another clarification: TYPE=Foo.Bar,Bread,Water is equivalent to Bread,Water,TYPE=Foo.Bar - in other words, Bread and Water are primitives not types. If this assumption isn't correct, then your example is broken in ways that cannot be fixed to operate as you describe without major LST changes [TRP]
 Insert comments on option #1 here.

@@ Line 72: / Line 72: @@
 ** CHOOSE:Subtoken|TYPE=Foo.TYPE=Bar,Bread,Water
 ** This would grant the choice of something with both the types Foo and Bar, or Bread or Water. Seems more intuitive that way. It also follows existing ADD syntax. ADD:ABILITY|AUTOMATIC|Foo,Bar,TYPE=Fun < See the PIPE delimits the Main Syntax Purpose:Token|Subtoken|Choice,Choice. [AM 5.1.09 @ 1:27 PDT]
 Insert comments on option #1 here.

@@ Line 131: / Line 131: @@
 *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.
+*Feels weird to use ampersand '&' as a delimiter. Delimiters should be simple '|,.[]():;' [AM]
 ==Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator==

@@ Line 69: / Line 69: @@
 * 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 [[User:Karianna|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.--[[User:Michael W. Fender|Fluxxdog]] 01:12, 2 April 2009 (CEST)
 Insert comments on option #1 here.

@@ Line 328: / Line 328: @@
 :::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files.  I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)
-::::[[User:Nuance|nuance]] I disagree, we would need to include the info in our Docs, but that's it.  People already need to read the docs to code in LST.  We have mailing lists where people can ask questions.  I think « and » are infinitely better than \ in this context.  \and\ is horrendously ugly and IMO hard to read.  Point is « and » are easy to type on the vast majority of keyboards/OSes.  Most poeple who can't figure out how to do something in lst ask or look at the distributed sets.  If they're looking at distributed data then—at the very least—they can cut and paste «AND» and «OR» into their own code.
+::::[[User:Nuance|nuance]] I disagree, we would need to include the info in our Docs, but that's it.
 :Hey coders!  Could we do something along the lines of <<and>>?  Using 2 '<' to signify a logical operator?  Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

@@ Line 235: / Line 235: @@
 * [[User:Nuance|nuance]] Backslashes—I hate this option.  It's hard to say how much I hate it.
 * [[User:Nuance|nuance]] Can I point out I'm also convinced we shouldn't use / or - in things like class names.  is CL=Funky-Gibbon asking for how many levels in class "Funky-Gibbon" or is it asking for how many levels in class "Funky" less the variable "Gibbon".  If I defined the variable Gibbon would it change the answer, what if I has class Funky and Variable Gibbon already defined and then defined class Funky-Gibbon?  Same argument with /  what does CL=Funky/Gibbon mean?
 Insert comments on option #3 here.

@@ Line 233: / Line 233: @@
 ::::::In the end, I won't be the one to make the final call.  But when that call is made, I'll have contributed something to the process, which is why I've joined with the team in the first place.
 ::::::And the rest of you just watching form the side lines, chime in!  Tom's right, 3 people can't haggle about this by themselves! :p --[[User:Michael W. Fender|Fluxxdog]] 02:26, 6 April 2009 (CEST)
 Insert comments on option #3 here.
@@ Line 320: / Line 325: @@
 ::: [http://en.wikipedia.org/wiki/Guillemets#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers| Typing the Guilemets « »]
 :::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files.  I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)
 :Hey coders!  Could we do something along the lines of <<and>>?  Using 2 '<' to signify a logical operator?  Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

@@ Line 230: / Line 230: @@
 :::If we go this route, is there any reason not to use the backslash for this?  I.E. \AND\ \OR\ --[[User:Michael W. Fender|Fluxxdog]] 01:14, 6 April 2009 (CEST)
 ::::* From a programming perspective, \AND\ is just as easy as a comma.  However, just to be clear, this process is to gather opinions, and we are missing some key players so far.  If the backslash is considered unclear, then that will be a major reason for it not to be used, and it will not be used.  You seem to have a strong opinion about this, but you need to give other people a chance to express their opinion as well.  Just because it is not used elsewhere, doesn't mean it is inevitable under this option. [TRP]
 Insert comments on option #3 here.

@@ Line 227: / Line 227: @@
 :If I'm wrong, please say so.--[[User:Michael W. Fender|Fluxxdog]] 16:26, 5 April 2009 (CEST)
 ::* If the path is to follow the spelled-out separators, then of the reserved characters (,|\:.[]%*=), .[]%= are already in the syntax and can't be used due to parsing problems.  : is our main token/value separator, and I'd really like to avoid that (though we can use it if necessary).  That leaves ,|\* of which only | is used elsewhere in the token (as a separator).  ,*\ all remain unused in the context of CHOOSE.  , is used elsewhere, but if we convert the other tokens, it would otherwise be unused. [TRP]
 Insert comments on option #3 here.