Literals UO"2C" = B"011_CCC"?

[valtih1978]

Now, what does the fact that value is the same as quadrupled '"'
character tell to us? What should the input bit_string_literal look like?

Section 15.8, says "For a character in the simplified value that is not
interpreted as an extended digit, each character in the replacement
sequence
is the same as the character replaced."

So if you run across a " or a "" in the input, it should be copied over as-is
into the output unchanged.

And now my question again: what should user input look like? I can copy
over '-' to get "----" in the resulting string literal value. What
should user enter to get '"' instead of '-'? Saying 'copy, as-is' means
that user should enter single "-mark in the bit vector literal instead
of -mark, right? Or what? Meantime you say that they need to be
duplicated to circumvent the BNF grammar.

Since a " would end up not being a legal bit value when you're all done
converting and an error is going to be flagged anyway, I would think
a compiler could stop and flag the error at that point.

I have heard that several times already and never received the answer
"why illegal". Who says 'illegal'? Why '-' is legal but '"' is illegal?
Should I constrain legal bit string values to those used in bit or
std_logic? My impression always was that user can define its own logic
values and use whatever characters are legal in the enumeration. Why is
'"' illegal? Is my convincing wrong?

Moreover, you say that bit vector has the same values as string_literal.
Does it mean that '"' is illegal in the string_literal?

I do not think that you can treat it equally with the issues that I have
raised.

Right, only things that you bring up are important. Gotcha.

First, this is a fascism. It is a fascism to say that "we are right
because these are we". Secondly, this is your position. You say LRM
creates a problem because your tool had a bug. But it is not, as we
explained. Third, you say that this is mine position, despite I discuss
the LRM rather than a bug in your tool. I have explained why there is no
problem with negatives. You should point to a flaw in my logic rather
than say that I must buy whatever you say or I am a unconscious bastard.

The double quote and physical unit is simply unparsable.
Well, other tools I assume are able to parse it, although I admit I
haven't bothered to try to insert a " into a bit string to see what
happens.

I have even looked in source code of such a tool. Why am I still here?

Yestuday, I have discovered one more conflict of this kind.

function_call ::= name [(args)]

How do you distinguish it from a simple identifier if arguments are not
specified?

In your example, 'name' will be the name of the function that has
already been defined previously in the source code as a function with
no arguments. The vocabulary keeps expanding as source code is
processed.
It starts with only the keywords, then adds on everything else that gets
declared. Not sure why you see any issue here.

Because "vocabulary" is the collection of scopes that you get during
elaboration, which seems to be a step supposed to happen after the parse
has finished. Meantime, VHDL seems to be context-sensitive language and
cannot parse without elaborating immediately. That is to parse a(b),
your parser must beware that a is a type or a function to choose a
corresponding grammar production, whether it should be a type conversion
or array indexing or function call. There should be elaborated model to
tell you that.

At the same time, LRM presents material as if elaboration is a thrid
step following 1) parsing and 2) analysis. All tools that I have used
perpetuate this approach when propose you to select the top level for
elaboration after parsing completed. The dilemma "to combine elaboration
with parsing or elaborate afterwards" leaves me very puzzled. Your hints
suggest that I must combine the two.

 

[valtih1978]

On 28.12.2015 21:18, Jim Lewis wrote:

The LRM is the conjunction of the BNF rules and the text. If a rule is
concisely and accurately specified in the BNF, then there is no additional text.
OTOH, some of the BNF is more general and the text provides further
constraints.

That was my impression. Thanks for explicating it. The problem is that I
started this thread because I could not find the additional text on bis
vector literals with embedded quote marks. Ok?

Perhaps you can download one of the free simulators and test out the cases you
are concerned about. IE, how other simulators handle " in a string.

I have even looked into the source code of the tool. I am not convinced
however that one implementation should be used as ultimate specification
when LRM is unclear. Why cannot people at compl.lang.vhdl simply provide
the missing narrative or point to the existing one?

 

[KJ]

On Tuesday, December 29, 2015 at 4:09:35 AM UTC-5, valtih1978 wrote:

Now, what does the fact that value is the same as quadrupled '"'
character tell to us? What should the input bit_string_literal look like?

Section 15.8, says "For a character in the simplified value that is not
interpreted as an extended digit, each character in the replacement
sequence
is the same as the character replaced."

So if you run across a " or a "" in the input, it should be copied over as-is
into the output unchanged.

And now my question again: what should user input look like?

And my answer again (last time though) is from section 15.8 "For a character in the simplified value that is not interpreted as an extended digit, each character in the replacement sequence is the same as the character replaced." So, if the character cannot be interpreted as an extended digit, then 'what comes in is what goes out...unchanged'. Can't be any clearer than that.

I can copy
over '-' to get "----" in the resulting string literal value.
Not according to my interpretation of the VHDL specification. Again, quoting section 15.8: (capitalized text is mine for emphasis, not for shouting)

"If the base specifier is O, UO, or SO, the digits 0 through 7 in the bit value are interpreted as extended digits, AND ALL OTHER GRAPHIC CHARACTERS ARE NOT INTERPRETED AS EXTENDED DIGITS. If the base specifier is X, UX or SX, all digits together with the letters A through F in the bit value are interpreted as extended digits. If the base specifier is D, all of the graphic characters in the bit value (not counting underline characters) shall be digits"

Now, you could look at that and say that the 'and all other graphic characters...' phrase only applies to octal format since that is conspicuously the only format that includes that phrase. However, like the octal format, the hex format clearly details which characters are extended digits so if you take some other character such as - or " it is clearly not an extended digit even without the phrase 'and all other graphic characters...'

No characters other than 0 thru 9 and A thru F are listed in the table that follows that defines the bit replacements for extended digits. Specifically, the character '-' is not listed so if you think that something is converting a single '-' into '----' than this conversion is something other than what the language specification is calling out in regards to a bit string literal.

What should user enter to get '"' instead of '-'? Saying 'copy, as-is' means that user should enter single "-mark in the bit vector literal instead
of -mark, right? Or what?

Input Output What it represents in the bit vector literal
- - The single dash character -, ASCII 45 or 2D hex
"" "" The single quotation mark ", ASCII 34 or 22 hex

Again, all of this is my interpretation of the LRM, everyone can have one. There is no ultimate authority that will issue a judgment on an interpretation of the standard declaring person #1 to be correct, person #2 to be incorrect. There is no Supreme Court of the VHDL standard. There used to be, but no longer. I've asked. So take whatever interpretation you think is best for your purposes and go run with it, that's what everyone else is doing.

Moreover, you say that bit vector has the same values as string_literal.
I quoted the VHDL specification.

I do not think that you can treat it equally with the issues that I have
raised.

Right, only things that you bring up are important. Gotcha.

First, this is a fascism. It is a fascism to say that "we are right
because these are we".

fascism ::= an authoritarian and nationalistic right-wing system of government and social organization.

I think not...and your use of that word in this forum clearly demonstrates your lack of any level of professionalism. Secondly your nonsensical quote "we are right because these are we" is not something attributable to me, only to you.

I've given you enough on this thread, so this will be my last. If you can't read the specification and interpret it yourself too bad. With the belligerent attitude that you demonstrate towards people who are attempting to help you at YOUR OWN request, I would suspect that you will have a hard time finding someone who will. People can have disagreements in this forum or elsewhere without going off like they are deranged, perhaps you should give it a try.

Secondly, this is your position. You say LRM
creates a problem because your tool had a bug.
I never said it was MY tool...and, for the record, it is not. But I see that you now agree that the tool has a bug...which seems to contradict your earlier position, but I don't care.

But it is not, as we explained.
That's your position

Third, you say that this is mine position, despite I discuss
the LRM rather than a bug in your tool.
I quoted and referenced the LRM, you, not so much. Again, it's not my tool..

I have explained why there is no
problem with negatives. You should point to a flaw in my logic rather
than say that I must buy whatever you say or I am a unconscious bastard.

I did point out the flaw in your logic and I'll repeat one last time. If there is a specific case where the LRM only allows a literal to be placed (and there are such places), AND the literal is a negative number such as -1, THEN according to the BNF defining the literal, the tool should flag an error BUT according to the narrative which also defines a literal, the negative number should be accepted.

I have even looked in source code of such a tool. Why am I still here?

I don't know. Why would you post a question that only you know the answer? Maybe you should go elsewhere and see if anything is any better over there.

Done with this thread. Be well.

Kevin Jennings

 

[rickman]

On 12/29/2015 7:57 PM, KJ wrote:

On Tuesday, December 29, 2015 at 4:09:35 AM UTC-5, valtih1978 wrote:
Now, what does the fact that value is the same as quadrupled
'"' character tell to us? What should the input
bit_string_literal look like?

Section 15.8, says "For a character in the simplified value that
is not interpreted as an extended digit, each character in the
replacement
sequence
is the same as the character replaced."

So if you run across a " or a "" in the input, it should be
copied over as-is into the output unchanged.

And now my question again: what should user input look like?

And my answer again (last time though) is from section 15.8 "For a
character in the simplified value that is not interpreted as an
extended digit, each character in the replacement sequence is the
same as the character replaced." So, if the character cannot be
interpreted as an extended digit, then 'what comes in is what goes
out...unchanged'. Can't be any clearer than that.

So the spec is saying that any character that is not treated as a digit
is to be inserted into the bit string "as-is". So any character that
does not "belong" to the bit string as in, not a valid value, will still
be inserted into the bit string and you will find out the error only
when some other part of the tool craps, not in the parser, right?

I can copy over '-' to get "----" in the resulting string literal
value.
Not according to my interpretation of the VHDL specification. Again,
quoting section 15.8: (capitalized text is mine for emphasis, not for
shouting)

"If the base specifier is O, UO, or SO, the digits 0 through 7 in the
bit value are interpreted as extended digits, AND ALL OTHER GRAPHIC
CHARACTERS ARE NOT INTERPRETED AS EXTENDED DIGITS. If the base
specifier is X, UX or SX, all digits together with the letters A
through F in the bit value are interpreted as extended digits. If the
base specifier is D, all of the graphic characters in the bit value
(not counting underline characters) shall be digits"

Now, you could look at that and say that the 'and all other graphic
characters...' phrase only applies to octal format since that is
conspicuously the only format that includes that phrase. However,
like the octal format, the hex format clearly details which
characters are extended digits so if you take some other character
such as - or " it is clearly not an extended digit even without the
phrase 'and all other graphic characters...'

No characters other than 0 thru 9 and A thru F are listed in the
table that follows that defines the bit replacements for extended
digits. Specifically, the character '-' is not listed so if you
think that something is converting a single '-' into '----' than this
conversion is something other than what the language specification is
calling out in regards to a bit string literal.

When converting a hex value I believe each non-hex character is assigned
to each of the four bits for that character. For an octal format aren't
non-octal characters assigned to three bit positions? Not sure how
decimal is handled...

--

Rick

 

[KJ]

On Tuesday, December 29, 2015 at 7:57:09 PM UTC-5, KJ wrote:

So if you run across a " or a "" in the input, it should be copied
over as-is into the output unchanged.

Actually, after re-reading, I see that I missed the following in section 15..8 where it says "the expanded bit value is the string obtained by replacing each character of the simplified bit value by a sequence of three (respectively four) characters." So any character like a - will be replicated three (for octal) or four times (for hex). Other than the digits 0-9 and characters A-F, the underline character is the only special case character since "The string literal is formed from the bit value by first obtaining a simplified bit value, consisting of the bit value with underline characters removed,..." which is to allow you to write "1111_1111" and more clearly see that it is eight bits.

Input Output Interpretation
- --- or ---- Three or four dashes depending on whether octal or hex
"" """""" or """""""" Three or four " depending on whether octal or hex

Kevin Jennings

 

[KJ]

On Tuesday, December 29, 2015 at 9:48:13 PM UTC-5, rickman wrote:

So the spec is saying that any character that is not treated as a digit
is to be inserted into the bit string "as-is". So any character that
does not "belong" to the bit string as in, not a valid value, will still
be inserted into the bit string and you will find out the error only
when some other part of the tool craps, not in the parser, right?

Yes, almost. I had missed the sentence that says those other characters will be replicated three or four times for octal and hex, but that just means that typing an 'M' as input will become 'MMM' or 'MMMM'. Secondly, the characters other than 0-9 and A-F are not invalid as far as being considered a bit string literal but you're correct that something downstream will hopefully complain when you try to interpret that bit string literal as a number as an example.

When converting a hex value I believe each non-hex character is assigned
to each of the four bits for that character. For an octal format aren't
non-octal characters assigned to three bit positions? Not sure how
decimal is handled...

Yes, you're correct. Again, I had missed the replication of the characters as previously mentioned. But the replicated characters can be any character other than the underscore.

For decimal, there is no mention of any replication of characters as there is with octal and hex so I interpret that meaning that D"35-" is an illegal bit vector literal (SX"3W" on the other hand is a legal literal). For decimal, it says "If the base specifier is D, the simplified bit value is interpreted as a decimal integer. The expanded bit value is a string of 0 and 1 digits that is the binary representation of the decimal integer. The number of characters in the expanded bit value is given by the expression , where n is the value of the decimal integer."

Kevin Jennings

 

[valtih1978]

You say that VHDL spec says me what to do with bit vector literals and
then say that there is not ultimate authority.


> copy as-is means

- - The single dash character -, ASCII 45 or 2D hex
"" "" The single quotation mark ", ASCII 34 or 22 hex

The fact you ignore again is that taking user intput "as-is" this way
will result in string literal value with duplicated quotation marks
embedded in it. Also, it is inconsistent with the issue of legality. You
say that doing it is illegal in the other parts of discussion, which is
not least puzzling.

I can copy
over '-' to get "----" in the resulting string literal value.

Not according to my interpretation of the VHDL specification. Again,

quoting section 15.8: (capitalized text is mine for emphasis, not for
shouting)

>"If the base specifier is O, UO, or SO, the digits 0 through 7 in the
bit value are interpreted as extended digits, AND ALL OTHER GRAPHIC
CHARACTERS ARE NOT INTERPRETED AS EXTENDED DIGITS. If the base specifier
is X, UX or SX, all digits together with the letters A through F in the
bit value are interpreted as extended digits. If the base specifier is
D, all of the graphic characters in the bit value (not counting
underline characters) shall be digits"

>Now, you could look at that and say that the 'and all other graphic
characters...' phrase only applies to octal format since that is
conspicuously the only format that includes that phrase. However, like
the octal format, the hex format clearly details which characters are
extended digits so if you take some other character such as - or " it is
clearly not an extended digit even without the phrase 'and all other
graphic characters...'

> No characters other than 0 thru 9 and A thru F are listed in the
table that follows that defines the bit replacements for extended
digits. Specifically, the character '-' is not listed so if you think
that something is converting a single '-' into '----' than this
conversion is something other than what the language specification is
calling out in regards to a bit string literal.

It is especially funny after

if the character cannot be interpreted as an extended digit, then
'what comes in is what goes out...unchanged'.

You seem not even notice that you have two contradictory statements, '-'
must be expanded into "----" and it must not, supported by the
specification. And you say that "It can't be any clearer than that". I
must be clearly stupid not to understand this contradiction, right?

I cannot build up a solid consistent picture of the pieces you shuffle
all the way.

Correcting myself, I obviously asked for validity of X"F-" => "1111----"
when written 16"F-". You seems to realized that when drawn attention to
impossibility to expand '-' into "----" according to VHDL spec. Just try
to interpret those examples from the same VHDL spec

12UX"F-" -- Equivalent to B"0000_1111_----"
UO"2C" -- Equivalent to B"011_CCC"

I started the topic with the latter one. C should not expand to CCC
since C isn't an octal digit, right?

> I never said it was MY tool...and, for the record, it is not. But I
see that you now agree that the tool has a bug...which seems to
contradict your earlier position, but I don't care.

You are calling me lier referring to something. Very nice. Prove. Where
did I contradict myself? Do you don't care so much to not bother to
provide the evidence?

fascism ::= an authoritarian and nationalistic right-wing system of
government and social organization. I think not...

As with other definitions, you pick up one, inappropriate one, and
demonstrate that opponent is an idiot. That seems very professional. How
old are you?

> and your use of that word in this forum clearly demonstrates your
lack of any level of professionalism. Secondly your nonsensical quote
"we are right because these are we" is not something attributable to me,
only to you.

Sure. The fact that you started to apply that name calling proves that
it is me who is a piece of crap. It was me who diverted from discussing
the substance into ad-hominem. These are mine words "only things that
you bring up are important. Gotcha." Clearly, I called opponents
fascists. Ad-hominem, based on ad-hominem makes you true professional.

Fascists are everybody who supress others, no matter others are right
because fascists define "right" exactly their point of view and
domination. We are right because this are we, I am right because this is
what I am telling you is a primitive nazi mind set. You probably was
never tried to understand political views, what are people struggling
for, if you reject this this as total bullshit. People do not struggle
for dictatorship or system of government. They struggle for "their
order". Here are "us", who must opress "them". That is fascism and it
means that "us = right", "them = wrong". You accused me in having this
stance.

With the belligerent attitude that you demonstrate towards people who
are attempting to help you at YOUR OWN request

I don't buy crap. Professionals never cover demagogy with "you are a bad
person because you reject the help that I kindly provide. You must
happily appreciate whatever I say or otherwise you are amoral person".
These are not professionals but fascists. Professionals address the
matter or pass by.

I raised an issue for interested people rather than those who just pick
arbitrary pieces of spec and force me to eat it without letting me to
build a solid picture.

BUT according to the narrative which also defines a literal, the
negative number should be accepted.

I can repeat my "contradictory earlier statement": the narrative says
that your account should support both positive and negative top-ups
whereas cache-in machine accepts only positive amounts. Using the
machine won't cause any failure whatsoever. You approach the machine,
put money in -- done. Never fails. Same with VHDL parser: you feed valid
number literals, BNF splits them into sign operation and (positive)
integer -- never fails. VHDL parsing never fails. Now, some madcap has
"fixed" the BNF and got some error. Why spec is to guilt?

Even Jim points out that narrative takes preference only to narrow the
BNF down:

some of the BNF is more general and the text provides further
constraints.

Your tool (nobody else cares about it -- it is your tool) instead did
the opposite. It took valid BNF and generalized it.

I am talking about situation where BNF fails and there seems no
narrative to figure out the stance on embedded quotation mark. That is a
real problem. You cannot parse VHDL. There is a big difference between
you can parser VHDL (there is not conflict) and you have not idea how to
do this. The former case resolves naturally. The latter has no
resolution (I have got none yet). Tell me what's more important.

I have even looked in source code of such a tool.
Why am I still here?

I don't know. Why would you post a question that only you know the
answer?

Somebody pointing out inconsistencies in your logic is not accepted in
this forum, for many reasons. Saying that "not eating my shit" =
"posting unanswerable question" is one of such reasons. You force me to
eat shit or get away. You is a true professionalism. Regards to that.

I only care about VHDL, not your tool or other tools. I want to know how
is it supposed to be, if it is my omission not being able to see
specified resolution or it is a real gap in the spec. Surely,
comp.lang.vhdl is not the place to figure this out.

 

[Brian Drummond]

On Mon, 28 Dec 2015 06:34:13 -0800, KJ wrote:

On Monday, December 28, 2015 at 8:11:29 AM UTC-5, Brian Drummond wrote:
On Sun, 27 Dec 2015 17:33:10 -0800, KJ wrote:

If you'd like another example of a discrepancy between BNF and the
text,
here you go...
Section 5.2.3.1 (General Integer types)
"An implementation may restrict the bounds of the range constraint of
integer types other than type universal_integer. However, an
implementation shall allow the declaration of any integer type whose
range is wholly contained within the bounds -2147483647 and
+2147483647 inclusive."

The term "literal" does not appear here,
snip
More precisely, any such statement is not part of the quoted material.
I haven't found one elsewhere either)

You didn't look too hard. I see you chose to write this before you read
the next paragraph that I wrote or the section that I referenced in the
specification. Maybe you'll read it this time.

section 5.2.3.1 (Integer types general)
"Integer literals are the literals of an anonymous predefined type that
is called universal_integer in this standard. Other integer types have
no literals. However, for each integer type there exists an implicit
conversion that converts a value of type universal_integer into the
corresponding value (if any) of the integer type (see 9.3.6)."

Right. However, to repeat, this neither states nor implies that the
integer literals are required to cover the full set of values.

And as we shall see, an integer literal is explicitly not an integer
value, but a textual representation of an integer value. This distinction
appears to be the source of the so-called "discrepancy".

To proceed...

Section 9.3.2 Literals "numeric_literal ::= abstract_literal |
physical_literal Numeric literals include literals of the abstract
types universal_integer and universal_real, as well as literals of
physical types. Abstract literals are defined in 15.5; physical
literals are defined in 5.2.4.1."

Nor does this state that the range of literals covers the entire range
of values.

You've gone off the deep end now. The sections I've cited do establish
the range.

Certainly I have gone off the deep end and I can name the exact time and
circumstance, but that's entirely irrelevant to *this* discussion.

The sections you have cited certainly establish the range of integer
*values* but not the range of integer *literals*.

So, clearly -1 should be considered a numeric literal.

I think that requires an inference that is not stated in the quoted
passages above.

Then you're part of the small group that accepts:
1. "Integer literals are the literals of an anonymous predefined type
that is called universal_integer" (5.2.3.1)
2. "Numeric literals include literals of the abstract types
universal_integer" (9.3.2)
3. "integer type whose range is wholly contained within the bounds
-2147483647 and +2147483647 inclusive." (5.2.3.1)
4. "...may restrict the bounds of the range constraint of integer types
other than type universal_integer" 5.2.3.1

None of which sections either identify *values* with *literals* nor
require the literals to cover the full span of values.

> But do not think that -1 is a numeric literal.

Indeed so. In a bit more detail, you have established via 9.3.2 that an
integer literal is an abstract literal. Which latter is ...

15.5.1
abstract_literal ::= decimal_literal | based_literal

15.5.2
decimal_literal ::= integer [ . integer ] [ exponent ]
integer ::= digit { [ underline ] digit }
(we can discount based literals)

Now here is the first problem : `-` is not a digit, thus forming no part
of the "integer" component of an abstract literal - despite the very
*cough* real existence of negative integer *values*.

To which you object the BNF must be incomplete or faulty, surely the text
will clarify ... and it does.

15.3 Lexical elements, separators, and delimiters
The text of each design unit, apart from text treated specially due to
the effect of tool directives (see 15.11), is a sequence of separate
lexical elements. Each lexical element is either a delimiter, an
identifier (which may be a reserved word), an abstract literal, a
character literal, a string literal, a bit string literal, a comment, ...

Note here the word "either" - meaning exclusivity.
And (still 15.3)

A delimiter is either one of the following special characters (in the
basic character set):
& ' ( ) * + , - . / : ; < = > ` | [ ] ? @

Now, it is established that '-' is a delimiter.
It CANNOT (thanks to "either") also form part of an abstract literal.

It is also established that an "abstract literal" is a "lexical element"
i.e. a textual representation of a value, which is certainly not the same
thing as the value itself.

Now, where is the minus sign in the BNF? It's not there.

Which suggests an alternative inference : only the naturals are
representable as literals; negative values are expressed as the result
of a negation operator on a positive literal.

So we are now left with ONLY this alternative inference.

Which contradicts the previously cited section 5.2.3.1 "integer type
whose range is wholly contained within the bounds -2147483647 and
+2147483647 inclusive."

Because literals /= values, and values /= literals, this is no
contradiction.

the BNF does not support this since there is no way to put in the
minus sign per the BNF. So these two sections of the specification
conflict.

The conflict exists only if the former section of the specification
actually exists, which is not established by the quoted material.

It is established, you don't accept it.

Oooohhh, noooo, it isn't!!!
(in honour of pantomime season... if you're in a benighted land without
pantomime, you'll just have to imagine that line delivered by an entire
audience of screaming children)

If there is something in the
language specification that says the narrative can be ignored in case of
a conflict with the BNF, ...

Because the narrative classes `-` as a delimiter, and thus explicitly not
a component of an abstract literal, the narrative and the BNF appear
fully in agreement in calling -1 the result of an operator with an
abstract literal argument. No conflict, no need to ignore either.

... then you would do well to quote that rather
than trundling down the path you're on.

I hope this has been satisfactorily clarified.

-- Brian

Kevin Jennings

 

[valtih1978]

Other than the digits 0-9 and characters A-F, the underline character
is the only special case character since "The string literal is
formed from the bit value by first obtaining a simplified bit value,
consisting of the bit value with underline characters removed,..."

and what is this

> ---- = Three or four dashes depending on whether octal or hex

You telling me how dash cannot become a part of output string literal
and immediately complement your words with understanding how it does.
Even 4 dashes instead of 1. Is string literal formed from them or not?
Which kind of logic do you use?

In VHDL, user can not only use the dash, which can you see only
selectively, but can exploit any /*graphic_*/characters for his bit
literals. All are accepted in string_literal, including all special
characters, including quotation mark. That is the story about. Telling
which characters are legitimate is fine but you better think a little
before dictating them for me to record. Try to check your rules for
consistency first. Building a solid picture helps a lot.