What I don't have a firm grasp on is how to explain it to others, that is all.
That is in my experience a sign of not having a firm enough grasp on the subject matter.
If you had a single grain of faith in my intelligence you would be able to figure it outbut you don't your completely and unfairly biased against me because I am having difficulty explaining it in a manner that you understand.
Please learn to restrain yourself and refrain from hurling insults.
| [reply] |
I am having difficulty explaining it in a manner that you understand Did you try to write it down in Backus-Naur-form? At least that would settle the format of the language and then you are already half way done in writing a compiler, well the parser part of it at least.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
<symbol> ::= <open> <name> <args> <close> <data> <open> <name> <clos
+e>
<open> ::= <primary> | <secondary> | <teriary>
<close> ::= <primary> | <secondary> | <teriary>
<name> ::= <string>
<args> ::= <key> <equals> <quote> <value> <quote>
...
<data> ::= <xml>
<primary> ::= <(> | <)>
<secondary> ::= <<> | <>>
<teriary> ::= <[> | <]>
Something like that, sorry if that's completely wrong I've never used BNF before.
| [reply]
[d/l] |
- aXML allows nested "symbols", but your grammar does not. ("Directives" might be a better name.)
- You're grammar allows <foo], but aXML does not.
- &lab; is conspicuously absent.
- None of the rules you gave make sense as the starting rule.
- Finally, the word "xml' should not appear in there at all. There's absolutely no requirement for aXML to be used for XML, you said.
| [reply]
[d/l]
[select] |
The little I know of BNF, I think your representation is not correct, but I leave it to more experienced Monks to look into it.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
What I don't have a firm grasp on is how to explain it to others, that is all.
If you can't explain it simply, you don't understand it well enough.
If you had a single grain of faith in my intelligence
I try not to involve myself in these threads more than I have to (and I'm failing at that). However, to have that type of faith would require a single grain of evidence. If you're an idiot as you think everyone here thinks you are, you'll take that to mean that I think you're an idiot. An inability to learn is not the same thing as being an idiot, so you'd be wrong (but, of course, proving that you actually are an idiot). If you are half as intelligent as you think you are, you'll understand that, from others' viewpoints here, you continue to say the same things over and over again, expecting a different outcome. That's not evidence of intelligence, it's the opposite. However, I understand it's mere evidence, not proof, so I wait, very patiently at this point, for evidence of this intelligence that you claim. If you want to make any progress with your invention, you'll need to show this evidence.
Note that one piece of evidence of intelligence is humility. And not false humility of the type that claims he's a victim or lashes out at others claiming that anyone but yourself is at fault for the misunderstanding. And not the false humility that puts "I'm sorry OK?????" in bold in a passive-aggressive attack. But the type of humility that starts by asking honest questions about what others don't understand about your position, going away to figure out how to better explain things, and not coming back until you do (unless it is to ask further honest questions about it). Communication is a two-way street. That means that you have a responsibility to the conversation to explain yourself well, and the listener has a responsibility to listen, comprehend, and ask questions of that which he has failed to comprehend. However, regardless of whether the other party is holding their end of the bargain or not, you can only control yourself. You cannot make someone else do something, you can only make yourself do something. It takes real humility to let go of any attempt to control or bully others, and only then will you start to make progress.
It's so simple, all this stuff that has been bandied about is all so complex
"For every complex problem, there is an answer that is clear, simple--and wrong." Perhaps with enough humility you'll eventually come to understand that you're solving a complex problem, and that requires a more complex solution. Passive-aggressive stances won't help. They'll only detract from any attempt at the grain of evidence above.
Oh Lord it's hard to be humble, when you're perfect in every way...
| [reply] |