Code is written by entering Strings with Reckon[String]. If "input" is a String, then...
(1) Reckon[String]["input"]
...attempts to parse "input"
in the current environment.
(2) Reckon[String][env]["input"]
...attempts to parse "input"
in the environment specified by the ContextSequence
env.
If "input" is a String whose
Characters are all
defined by a RuleList
(used to specify a named CharacterSet),
then......
Reckon[String][env]["input"]
...can interpret any String,
regardless of it's CharacterSet because
characters are interpreted as Noops,
Digits,
Letters,
ParaPuncs,
or Operators assigned when a CharacterSet is
declared. The five CharacterSet
defining Lists, are written into the
CharacterStream Function. This Function
is assigned to Reckon[String][Function].
A CharacterSet
is declared as follows:
(3) String[Name["charSetNam"]][RuleList ]
...where RuleList = {Noops, Digits, Letters, ParaPuncs, Operators}.
The recognition algorithm in Reckon[String]
recognizes which subList within ruleList (see below) a character is in, and its position within that
List. See CharacterSet.
Reckon[String][Function]
is assigned to the CharacterStream parsing Function which applies the RuleList
of the operant CharacterSet.
Name[Reckon[String][Function][input_String],
Tally[CharacterFunction[Slot], input]
]
(* Mostly, CharacterFunction[chr] returns Noop on each Character iteration.
This is because it is only supposed to return a single String result,
if it successfully parses the input String (into an interpretable Grok32` Expression.).
Every other iteration, every Character iteration is conditional; Noop
is returned if Reckoning has not yet failed.
Alternately, couldn't Loop be, like Slot, and Noop?
Is there any difference in Loop and Noop in a Tally
construction?
*)
Name[CharacterFunction[chr_Character],
With[{ChrType=CharacterType[chr]},
Switch[ChrType,
ExpressionCharacterMachine[chr]
]
]
]
Disjoint-ParaPunc-Ordered adj.
When ParaPuncs
in a character sequence are disjoint, the
span of one discrete element does not share any characters with the span of
another element, unless one is wholly contained within the other. By contrast, a non-Disjoint-ParaPunc-Ordered
has elements which may share spans with other elements. It
is the job of the ReckonString
ParaPunc exception routine to render Expressions
so they have disjoint ParaPuncs.
The ruleList and the basic mechanism for interpreting Expressions (See ExpressionParing.), is generally sufficient for modeling most language syntax that is Disjoint-ParaPunc-Ordered. Sometimes, however, character Strings do not have disjoint ParaPuncs.
For example, written English has the convention of placing
the periods within quotations that appear at the end of sentences. For example, the sentence,
Bob said, "Hello."
...is an example of a non disjoint ParaPunc. Periods (and other sentence-ending punctuation marks) separate
the sentences that comprise paragraphs. Quotations
used in sentences are usually single words or phrases which are part of a
sentence. Thus, to put a quotation mark to the right
of a sentence's period is an exception to the general rule that a sentences
subcomponents (words, phrases, quotes) exist exclusively between sentence
start and end. A Disjoint-ParaPunc-Ordered
version of the above sentence would be:
Bob said, "Hello".
While the above version is syntactically wrong, its form would be generated
as an intermediate step in parsing the sentence in Grok32`.
Many languages have merged ParaPuncs
, which are usually the result of some feature in the String's visual or
auditory presentation.
In general, whenever a non-disjoint (merged) ParaPunc
is encountered, a list of rules are scanned for a matching exception pattern. If such exception pattern is not matched, an error message
is output.
The RuleList for interpreting input Strings makes it possible for Grok32` to emulate other languages, and write elegant code. The default assumption is that the RuleList used to parse input Strings contains the rules the user wants applied to the output.
For example, internally, False is
represented as Not[True]...
Name[Not[True], False]
This interpretation is useful for some kinds of Reckoning ... and sometimes
not.
(c) 2004-2007 by
John Van Wie Bergamini.
All rights reserved.