Reworded parts on premake of Lua-Serialization article

1 files changed, 13 insertions, 13 deletions

diff --git a/lua_as_human_readable_serialization_format.html b/lua_as_human_readable_serialization_format.html
index 1802aa1..75e6117 100644
--- a/lua_as_human_readable_serialization_format.html
+++ b/lua_as_human_readable_serialization_format.html
@@ -33,10 +33,10 @@ return {
 	position = {x=0, y=0},
 }
 </pre>
-<p>This makes use of how <a href="https://www.lua.org/manual/5.4/manual.html#6.3">modules</a> and importing them works.
-In short, module script is interpreted and value of the final <code>return</code> is used as the value for the "module".
-In this case the script is a lone return-statement with no logic involved. This somewhat declarative-like style is
-purely conventional. More commonly the returned value is a table of functions, exactly what we would consider a "normal
+<p>This makes use of how <a href="https://www.lua.org/manual/5.4/manual.html#6.3">modules</a> are imported. In short,
+module script is interpreted and value of the final <code>return</code> is used as the value for the "module". In this
+case the script is a lone return-statement with no logic involved. This somewhat declarative-like style is purely
+conventional. More commonly the returned value is a table of functions, exactly what we would consider a "normal
 module", or a class.
 <p>In the example above we are not really sure what kind of thing we are dealing with. To stay consistent we could add a
 <code>type = "slime",</code> to the table. Now reader would know what they are dealing with. Of course, scheme would
@@ -63,15 +63,15 @@ Slime {
 	position = Vec2{x=0, y=0},
 }
 </pre>
-<p>It now looks like some generic markup language. But the module loading mechanism will no longer work for us. Instead
-reader needs to use <a href="https://www.lua.org/manual/5.4/manual.html#pdf-load">load</a>. It conveniently has an
-option to specify execution environment. Additionally, a mechanism for tracking top-level statements in one way or
-another is needed.
-<p>This approach is somewhat similar to what <a href="https://premake.github.io/">Premake</a> does. Surprisingly, this
-is also pretty close to regular register-event-callback approach for plugin systems (e.g., in
-<a href="https://github.com/martanne/vis">vis</a>). How so? The "tracking top-level statements" will result in a
-side-effect in some global or loader state. In callback approach, it's the event dispatcher or otherwise plugin system
-state that fulfils similar role. Additionally, API is usually exposed through environment (and not e.g., user function
+<p>It now looks like generic markup language but the module loading mechanism will no longer work for us. Instead
+reader needs to <a href="https://www.lua.org/manual/5.4/manual.html#pdf-load">load</a> it and execute. Functions
+handling data types here are expected to cause side-effects in order to record the entries. This may be coupled with a
+way of detecting top-level statements. Load conveniently has an option to specify execution environment.
+<p>This approach is somewhat similar to what <a href="https://premake.github.io/">Premake</a> does. And surprisingly,
+this is also pretty close to a regular register-event-callback approach that some plugin systems use (e.g.,
+<a href="https://github.com/martanne/vis">vis</a>). How so? Here, point is to modify loader state as side-effect. In
+callback approach, when plugin is loading it has access to register itself for certain events, modifying the plugin or
+event system's state. Additionally, API is usually exposed through an environment (and not e.g., user function
 argument and plugin returned as module never able to directly interact with the API).
 <p>For my standards definitions I settled for the last style. It allows for multiple items without indention and I liked
 the idea at the time. It allowed me to play around and neatly layer parser, environment, and model. Final definitions