I will gladly pay you Tuesday for a Hnakkerbröd today.

Beware: when speaking to Trolls, listen carefully. It could save your ice hole.
        (Trolls are known for their skill in wintertime fishing.)

My software, courtesy of MediaFire:

https://www.mediafire.com/?ebbyj47e35mmytg (http://www.mediafire.com/download/ebbyj47e35mmytg/mlptk-qlupgradecomplete-awaitingspeedfix-27mar2016.zip)

This update (unlike the foregoing, which fixed the Opera bug) regards only QL.
Again: Quadrare Lexema is similar to GNU Bison. If an infringement, I'll delete
it as soon as I hear or see from you. BTW, Bison is time-tested; QL isn't.

Oh, and a correction to "First Rate?": Bison can indeed unshift multiple tokens
back onto its input stream, even though productions can't be multiple symbols in
length, by unshifting directly onto its input during reduction (which is how QL
does it too, during deferment, which amounts to the same exact thing because no
reason exists to compute anything during deferment -- otherwise, there'd be more
race conditions than the Kentucky Derby, which is very silly).

QL is now "kinda-sorta" debugged and functioning to my specification AFAICT. Now
the API has changed considerably from how it was last month (the argument vector
to reduction deferment class constructors has been modified, some new faculties
now exist, and some were removed); this necessitated additional instantiations
of "new Array()," and interolably reduces efficiency when operating on very long
inputs, but I wanted to hurry-up this design iteration. (That was one sentence.)

The token agglutination mechanism of the parser logic is the same as before.
Code to determine precedence & blocking has been abridged; toddling steps toward
a method to generate the parser as in-line code. (As you see, that isn't yet.)

I'm tempted to redo the infrastructure to reduce the number of new Array()s that
are instantiated during the parse phase, but I'm pretty sure I can do that by
rewriting the underlying code without changing the API. The interface between
the parser's stack extremum and its input stream is passed to reductions as an
Array(), but that doesn't mean it always has to be allocated anew.

Remember: the old Command Line Interpretation Translator scaffold isn't decided;
I left ::toTheLimit() where it was, pending a ::hatten() that shall suit you; if
you'd like to use the horrifying monstrosity that is my software architecture,
you can see Mr. Skeleton awaiting you in clit.js -- asking where is his flesh, &
rapidly becoming impatient with my poking and prodding him all day. Soon, Mr.
Skeleton; soon shall be the day when the hat is yours at last, & your calcareous
projection from within my library becomes a fully fledged automaton unto itself.

For the meantime I'm satisfied with the half-measure. I think the API is okay to
start building upon, so I'll start building. Overhaul of the back-end late this
year or early in the next, & it's looking good for me to furnish the CLIT before
the third quarter. Therefore I'd say: expect full CLIT functionality in 2016.

Before I apprise you of my progress so far, let's take a moment for a thoroughly
detailed technical analysis of Mr. Skeleton's bony protrusion.

Phoneme    <=    (EscapeSequence | AnyCharacter | Number | String)
                 (EscapeSequence | AnyCharacter | Number | String | Phoneme | )
	Concatenate a "word" that is one argument in an argument vector.

ISLDQ    <=    '\"'
	Open a <String>.

InchoateString    <=    (ISLDQ | InchoateString)
                        (OP_CAT | OP_CONJ | EscapeSequence | AnyCharacter
                         | Number | Space)
	Make strings out of any symbol following an open string.
	(As you can see, this rule must be rewritten...)

String    <=    InchoateString '\"'
	Close a <String>.

Argument    <=    Phoneme (Space | ) | Argument Argument
	Concatenate the argument vector comprising an executable MLPTK command.
	That bit with "(Space | )" should probably be just "Space".

Catenation    <=    (Argument | Group | Conjugation) OP_CAT
	Concatenate the output of commands.

MalformedGroupCohesion    <=    (Argument | Group | Conjugation) OP_CLPAR
	Automatically correct the user's malformed syntax where the last
	command in a parenthetical sub-grouping was not followed by a ";".

ExecutableInchoateConjugation    <=    Argument OP_CONJ | Blargument
	Signify that a command can be executed as part of a <Conjugation>.

InchoateConjugation    <=    Group OP_CONJ | Conjugation
	Convert a conjugated <Group>, or the output of a <Conjugation>,
	to an <InchoateConjugation> token that can form the left-hand
	part of a further <Conjugation>.
	This reduction causes parser stack differentiation, because it
	conflicts with "Catenation <= Conjugation OP_CAT".
	In that circumstance, the sequence "<Conjugation> <OP_CAT> ..."
	is both a "<Catenation> ..." and a "<InchoateConjugation> <OP_CAT> ...".
	Observe that the latter always produces a syntax error.
	I'm pretty sure I could rewrite the grammar of the <Conjugation> rule to
	fix this; IDK why I didn't. (Maybe a bug elsewhere makes it impossible.)

Conjugation    <=    (ExecutableInchoateConjugation | InchoateConjugation)
	Execute the command in the <ExecutableInchoateConjugation> at right,
	supplying on its standard input the standard output of that at left.

InchoateGroup    <=    (OP_OPPAR | InchoateGroup) Catenation
	Concatenate the contents of a parenthesized command sub-grouping.

Group    <=    InchoateGroup (OP_CLPAR | MalformedGroupCohesion)
	Close an <InchoateGroup>. Concatenate the contents of a
	<MalformedGroupCohesion> if it trailed.

CommandLine    <=    (CommandLine | ) Catenation
	Concatenate the output of <Catenation>s into one Array.
	This one actually doesn't differentiate. Either a <CommandLine> waits at
	left to consume a Catenation when it reduces, or something else does, &
	<Catenations> in mid-parse never reduce to <CommandLine>s except when
	fatal syntax errors occur, in which case the parser belches brimstone.
Blargument    <=    Argument (OP_CAT | OP_CLPAR)
    Duplicate the trailing concatenation operator or close parenthesis following
    an <Argument>, so that a <Conjugation> doesn't conflict with a <Catenation>
    or an <InchoateGroupCohesion>. I think this can be specified formally in a
    proper grammar, without the multiple-symbol unshift, but IDK how just yet --
    because (without lookahead) the parser can't know when the argument vector
    ends without seeing a trailing operator, so execution of the last command in
    the conjugation sequence <InchoateConjugation> <Argument> <OP_CAT> would
    occur when <Argument> <OP_CAT> reduces & executes, disregarding its standard
    input (the contents of the foregoing <InchoateConjugation>.
    "Blargument <= Argument" can never happen and "ExecutableInchoateConjugation
    <= Argument" would grab the <Argument> before it could concatenate with the
    next <Argument>, so I'm at a loss for how I should accomplish this formally.
    BTW, <Blargument> is the <WalkingBassline>, with trivial alterations.
    The <Blargument> reduction causes parser stack differentiation, because it
    conflicts with both <Catenation> and <MalformedGroupCohesion>. In either
    case, the <Blargument> branch encounters a syntax error & disappears
    when <Blargument> didn't immediately follow an inchoate conjugation; the
    other branch disappears in the inverse circumstance.

Token identifier   Operator precedence  Associativity
"Space", - - - - - 2, - - - - - - - - - "wrong",
"OP_CAT",  - - - - 0, - - - - - - - - - "wrong",
"EscapeSequence",  0, - - - - - - - - - "right",
"AnyCharacter",  - 0, - - - - - - - - - "right", (the sequence to the right of
"Number",  - - - - 0, - - - - - - - - - "right",  a right-associative token is
"String",  - - - - 0, - - - - - - - - - "right",  reduced first, except...)
"OP_OPPAR",  - - - 0, - - - - - - - - - "left",
"OP_CLPAR",  - - - 0, - - - - - - - - - "wrong", (... when wrong-associativity
"OP_CONJ", - - - - 0, - - - - - - - - - "wrong",  forces QL to reduce the right-
"QL_FINALIZE", - - 0, - - - - - - - - - "wrong"   associative sequence.)

The avid reader shall observe that my "wrong-associativity" specifier, when used
to define runs of right-associative tokens that stick to one another, is similar
to the lexical comparison & matching algorithm of a lexical analyzer (scanner).
In fact, as written, it _is_ a scanner. For an amusing diversion, try excerpting
the portions of the semantical analyzer (parser) that can be made into lexical
analyzer rules, then put them into the scanner; or wait a few months and I will.

But that's enough bony baloney.
If you preferred Mr. Skeleton as he was, see mlptk/old/clit.js.21mar2016.

As of probably a few days before I posted this brief, my upgrade to QL is now
sufficient to function vice its predecessor. I spruced-up Mr. Skeleton, so that
the test scaffold in clit.js now functions with ::hattenArDin() in QL, and now
everything looks all ready to go for shell arithmetic & such frills as that.

Ironically, it seems that I've made it slower by attempting to make it faster. I
 should have known better. I'll try to fix the speed problem soon; however,
until then, I've abandoned work on the Translator due to intolerable slowness.
I'm sorry for the inconvenience. If it's any help, I think the problem is due to
 too many new Array() invocations or too many nested Arrays, one of the two.
Either way, I intend to fix it this year by rewriting the whole parser (again)
as a static code generator.

I was also thinking of writing a windowing operating system for EmotoSys, but I
am uncertain how or whether to put clickable windows in the text console. I mean
-- it'd be simple now that QL's rolling, but maybe a more Spartan design? I will
post some flowcharts here when I've exhausted my ministrations to the CLIT.

Be careful what you say. The U.S.A. is not as free a country as you have been led to believe.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s