retro html formatted by nom
comments/suggestions to: mjb at nomlang dot org
<quote>
As I have previously mentioned, the nom system has continuously thrown up new ideas from the original core idea. One of the first was that I could write a nom script in order to compile nom into an intermediate format (which looks a bit like an assembly language). This intermediate format (and I got the term from a very cursory reading of the LLVM introduction) can be loaded directly by the (clang implementation of the) pep interpreter.
The pep interpreter leaves behind evidence of this intermediate format in the
form of a file called /sav.pp which is just a text file with instructions that
manipulate the pep virtual machine. This file represents a compiled script,
and every script gets compiled into this format before it is executed by the
/pep interpreter. Since the nom language is implemented by a nom script (which
is called /compile.pss ), it follows that there is also an assembler (or
intermediate format) file for the language implementer. This is called /asm.pp
. Unlike the sav.pp files which are compiled everytime a script is run (even
though they don’t have to be), the asm.pp file is normally only compiled (by
me) when I make some tweak to the nom language and it’s compiler.
Following this, numerous other ideas have emerged, such as the idea of nom scripts documenting themselves, as well as translating themselves to other (computer) languages. This latter idea has proved quite powerful and absorbing and is the basis of all the translation scripts which are in the /tr folder. These translation scripts allow any nom script to be translated into several languages such as dart, lua, java, javascript, perl, python and others.
Another important idea that arose was that of using grammar tokens to implement
an error and help system for all significant scripts: The idea is that instead
of throwing an error, a nom script creates an error token , and push es
it onto the stack and then calls the .reparse command. Furthermore,
a help token can be pushed onto the stack before the error token, where the
help token contains (on the tape ) some helpful information about to
fix the error that occurred. This system works well and makes it much easier
to write "helpful* compilers or parsers or recognisers.
It is an odd pursuit to write blog posts that possibly nobody reads, but
it serves to clarify my ideas and maybe even to act as a “thought experiment” .
Recently I implemented the system command. This command gives nom the
ability to create what I like to call (with limited justification)
"Tiny Language Models" . Whereas a Large Language Model is the basis of the
startlingly powerful Artificial Intelligence engines, a Tiny Language Model is
a way of writing parsers and responders for very specific contexts (such as
manipulating image files with standard command-line linux tools, for example).
The idea is quite simple: Some scripting language provides a loop (which will
become a read-execute-print-loop) and it also provides the maintaining of some
state - for example, “which image file are we currently discussing?” or
“to which server are we currently uploading files?” . This primitive state
management can be used to implement words like “this” that or “to there” .
On the other hand, pep and nom will provide the parsing and response logic,
firstly parsing the natural language input and then converting these
“queries” and “commands” into concrete actions or replies. The system
command allows this to work by reading the current state from the environment
and also executing the requested action.
All this is really just a glorified “chatbot” but it puts the role of simple grammar parsing into the centre of the problem. Programmers don’t generally think about grammatical patterns as a central part of their work. They think in terms of data structures, data transfer, logic and algorithms and input and output. But grammatical patterns seem to me to be more important, or at least, more interesting.