How would you simulate a programming language in the language Lua?

I have an idea for a project, which would basically be, create a simple programming language in lua.
I however, have no idea how you would simulate a language in lua, so I was hoping if any of you could give me some tips/guidelines, etc.

Thanks in advance.

What do you mean by "simulate"?

I think he means to make an interpreter for a supposed language in Lua.

I think he means another language, like LuaLua, which changes some things. We all have different ideas! Which one OP? D:

Yes, but you do need to write an interpreter for a supposed language in Lua (afaik) for it to be compatible without modding ComputerCraft.zip/Server Mods/etc.

I'm writing one called DeathCode, where you can customize your own 'words' to be put into the language, and it gets compiled into Lua, but it's easier to program in for some people. I find it fairly easy to take the code string, convert it into a lua function in a STRING then using loadstring to run the function.

Personally, I wouldn't know how to do this with out hundreds of message if statements. However, GravityScore made an interpreter for Brainf••k , now it's probably hard to read/use the assembly, but it's a start.

Do some research into compiler theory. It's pretty complicated stuff, but very interesting.

Yeah, I was talking about designing a basic programming language, and using lua as a interpreter for that.
I have heard and read that's it's really complicated, so I'll read up on the compiler theory as Yevano suggested for now.

Look up compiler and interpreter. Get familiar with what they are/do. Then you need to be looking at parsing the information.

Brainfuck already mentioned above is actually quite easy to write a compiler or an interpreter for. Assembly code is often easy enough to directly interpret or compile. Something high level is much harder, but people manage to do it at home as a hobby.

What your after is perfectly doable. Its difficult though but is highly rewarding if pulled off.

The simpler the language the easier it is to do in general.



I haven't heard of anyone writing interpreters in lua, although looking above it seems people have done stuff with computercraft and I'm sure if I hit google I'll see some more. I personally only ever got as far as writing a *very* crude assembler for a 16 bit CPU I made up in C#, I did write an emulator for it aswell (also C#), actually I wrote its entire instruction set in a notepad which I do still have under my bed so I might have a go at redoing that, dunno if I have the emulator or assembler still but I'll just start over. Did a simple brainfuck interpreter too in python.

ChunkSpy is a Lua assembler/disassembler which converts Lua source code to Lua bytecode and back, using an intermediate assembly-like language. The most powerful/efficient method would be compiling to assembly, then assembling to bytecode. ChunkSpy has some interesting methods for the second part.

Plus, if you implement it with an intermediate assembly-like language, it would be easier to decompile to the source code again (unless it was obfuscated).

A nice example and start-off for starting making programming languages is the Yueling Project. (http://luaforge.net/projects/yueliang/)

You can see: the first thing you CAN do is the input stream. You can use the fs.open stream too, but it's good to have some buffers and utilities built in.
Then, a lexer (lexical analyser) analyses everything, and returns Tokens. So like, if you have some digit's gotten in the stream, it parses it into "TOK_NUMBER" with an argument of the value of the number. Things like keywords have a token too. (f.e.: "public" can have the token "TOK_PUBLIC"). It's more efficient when you learn your lexer to parse strings and paths. Doing this in the parser just prevents it from it's work. The lexer doesn't check for errors or unexpected tokens. Only things like unprintable characters are throwing errors there. I wouldn't copy the lexer from yueliang, because it isn't that smart or efficient.

Then, you have the parser, the biggest part of the project. The parser uses the tokens of the lexer to build statements and DOES check for unexpected tokens or other errors. Here you have to choose how you want your language to look like.

Now the bytecode is built (in the parser too), but it would be less complicated and cross-platform when you parse the statements into lua, not into lua bytecodes.


I'm developing a custom language too, and I'm currently at the parser part, but once you've finished the statement parsing it gets alot easier.

ardera, on 08 April 2014 - 03:40 PM said:

Now the bytecode is built (in the parser too), but it would be less complicated and cross-platform when you parse the statements into lua, not into lua bytecodes.

Just to clarify, bytecode is generated after the parsing step, not during. I wouldn't really call that part of the parser. The abstract syntax tree must first be formed before you can know completely how to generate the bytecode. (Although this is probably most true for optimizations and in languages with static typing) I usually use the word "generator" for this step.

Yevano, on 08 April 2014 - 09:11 PM said:

Just to clarify, bytecode is generated after the parsing step, not during. I wouldn't really call that part of the parser. The abstract syntax tree must first be formed before you can know completely how to generate the bytecode. (Although this is probably most true for optimizations and in languages with static typing) I usually use the word "generator" for this step.

Yes, forgot about that, yueliang implemented it's generator in the parser, but LuaJ for example has some extra classes for that.