In this section of course we're going to take a look at the interpreter design pattern and the interpreter.
It's really everywhere.
Interpreters I mean if you're a programmer then the interpreter design pattern you being surrounded
by.
Because when you compile a language or when you use an interpreter.
So when you have an interpreted language that is all done by virtue of the interpreter the design pattern
now actually inter-party there isn't.
I wouldn't call it a design pattern.
I would say it's a separate branch of computer science which deals with how to write parsers how to
interpret data and how to subsequently output that data may be it into native code for example.
So it is something which could result us having yet another 10 hour course simply on the different parsers
and how to construct them and the kind of outputs they can have and so on and so forth which is all
very interesting but we don't have that much time here.
So the basic idea is that you have some textual input that needs to be processed.
Now I would argue also that the idea of taking text and then processing it for compilation for example
is a bit outdated.
There are alternatives to using tax such as projects.
No editor is like Giedd brains.
For example that's a good example of something that's more progressive.
But at the moment when you work with C++ or any other most programming languages you'll work with plain
text and this text needs to be processed and needs to be turned into some sort of object oriented representation
typically.
Well we live in an object oriented paradigm.
Unfortunately that's just the way things are.
So some examples of where the interpreter design pattern shows up is obviously the programming language
compilers the interpreters.
Even the integrated development environment because what happens when you have a static analysis done
by a tool like Sea-Lion or reshow C++ what really happens behind the scenes is that there is a process
which takes all your sourcecode and it has to interpret that before he can make some decisions about
the validity of certain structures that you are using or certain statements that you're writing.
And this is done via what's being called an interpreter design patterns simply we have simpler formats
like a female or a male or something to that effect which is also you know a separate representation
that has to be parsed has to be interpreted somehow.
We have simple things like numeric expressions you right 3PL us for the Y by five in a tool like Matlab
and the two has to basically interpret this expression as you know a set of instructions basically.
So whether it compiles it to some native code or whether it has a virtual machine of some kind or whether
it's just using interpretation without compilation doesn't really matter it's still the interpreter
pattern.
Another example a more sophisticated example is regular expressions.
Now regular expressions appear as chunks of text.
So you have this kind of domain specific language for interpreting strings.
But what really happens when you compile regular expressions is quite often you build state machines
you might build them at runtime or the compile time it doesn't really matter it really depends on the
implementation.
But the end result is you still have to take the sophisticated language which is being put into a string
and you have to turn it into some state machine which actually takes some inputs and then tries to match
that input onto the state machine and see whether it succeeds or fails.
So the challenge of the interpreter design pattern is turning strings into object oriented structures.
And it's a complicated process unfortunately there is no easy solution to all of this and certainly
the languages that we work with nowadays like C++ they are extremely complicated.
And as a result interpreting them is a particular challenge so they interpret that design pattern is
nothing more than a component which processes structure text data and it does so by typically splitting
the processing into two stages.
Now it really depends on the kind of language that you work with.
But in the general case we have these two stages called lexing and parsing.
So lexing is when you take the input and you split it into separate tokens split it into different self-contained
pieces of information with no semantic meaning they just.
For example if you have a mathematical expression you would just split it into numbers and the operators
like plus and minus and the round brackets and so on.
And then the second stage is the parsing that's when you take the sequence and that's when you try to
turn it into some sort of meaningful object oriented representation.