Stacking states to sublimate or cultivate an emotrait leads me to etiolate.

Emotrait: a portmanteau from emotion and trait (L. tractus, trahere, to draw),
          signifying what is thought of an individual when judging by emotion.
Etiolate: to blanch, or become white; as, by cloistering away from the sun.

IDK whether there is precisely twenty percent more QL by now, but I've tightened
the parser code and QL is now better than before. Nothing much new in MLPTK: I
fixed a few typos; that's about all. Today's installment is, courtesy MediaFire:

https://www.mediafire.com/?5my42sl41rywzsg (http://www.mediafire.com/download/5my42sl41rywzsg/mlptk-qlds14mar2016.zip)

As usual, my work is free of charge within the Public Domain.

The parser's state logic is exactly the same as it was before; but, in addition
to the changes I described (extremum-input interface differentiation) two posts
ago in the foregoing brief, I've altered the format of sequence reductions such
that the argument vector is now two args wide, comprising the interface triplet
(a parser stack node, a thread index, and a file handle into the thread) and a
reference to the parser object. Oh, and I depreciated the "mate" and "stop"
associativity specifiers, because making them work the way I wanted would have
been a nightmare.

And, even though Luna feels better after eating forty Snickers, that's terrible.

Anyway, let me bend your ear (eye?) for a while about the interface and handles.

The parse stack is more slender, but mostly the same, except that nodes are now
Arrays whose members point backward and forward in the stack. The parser's input
is stored (although I call this sometimes, erroneously, "buffering;" buffers do
not work that way) in a data structure named the input stream, which is a random
access virtual file that stores each token as an array element in itself. Again,
the input stream is not a buffer; it is a file that grows in size as tokens are
unshifted. This makes it unsuitable for very large inputs. I'll fix it soon. For
now, you'll have to put up with the memory leak. Maybe you can find some use for
it as a volatile file system or something, but it's useless as a buffer; what it
should have been in the first place. To fix the problem shall require only that
the object is made simpler, so I expect to have it improved by next update. In
the meantime, it functions by mapping an Array to a vector table whose indices
correspond to the Nth item in the data and whose values are the indices of that
item in the Array (which has certainly become fragmented).

That's about all that's developed since last time. As you can see @ hattenArDin,
I'm crafting QL as a quasi static code generator, with fewer heuristics. Instead
of storing within the parser stack nodes the information necessary to transition
the parser's state, Hatten walks the state map to determine exactly what symbols
transition, block, or reduce and whether they are right-associative. I could
also have done this for the precedence decision, but that would require that the
parser generator creates a significant number of additional states: like about
the number of symbols whose precedence is specified multiplied by the number of
symbols that can possibly occur anywhere in any sequence. In other words, such a
computational speed gain (one if-statement) would be about the square of present
memory consumption, or vaguely proximal to that. So that design decision was due
to my failure to ponder the math before writing, and not due to impossibility.
I'll work that problem, too, before I think I'm done improving the blueprint.

I could excerpt some code and walk you through it or something, but it is plain
language to me, and I have no idea how to make it any plainer in English unless
someone asks a question. I think WordPress is set to email me if you comment on
one of my posts, so I should see your letters if they ever arrive.

And, sadly, the tightened code is yet again "sorta functional." If you require a
testbed for your grammar, refer to the test sequence in clit.js & ::toTheLimit()
in quadrare-lexema.js; both of which work well enough, except for recursion.

Tentatively: expect the New & Improved Quadrare Lexema sometime around June.
Advertisements

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