Objective Lua - additional syntax to original Lua!

[lauriszz123]

Objective Lua

What is Objective Lua?
Objective Lua is a programming language that implements class support in Lua for Love2D without modifying vanilla Lua.

Implementation
It is fairly easy, just implement this snippet of code in the first line of your project code:

Code: Select all

main = require "olua.lua"

And done, you started using Objective Lua.

Example
Let's start with main.lua file:

Code: Select all

main = require "olua.lua"

function love.update( dt )
	main:update( dt )
end

function love.draw()
	main:draw()
end

Once we done that, we can start with coding our first class.
But remember that all classes need to be in classes folder inside your project folder.
classes/Main.olua:

Code: Select all

class Main
	function Main()
		self.width = 32
		self.height = 32
		self.x = 100
		self.y = 200
	end
	
	function update()
	
	end
	
	function draw()
		love.graphics.rectangle( "fill", self.x, self.y, self.width, self.height )
	end
end

And Like that we have our first working program! It's that simple!

Download and more Information

Added new keywords: class, inherits, new, instanceof

SublimeText support with Love2D!

You can download the project in my GitHub repo here. Also, look around, read a bit, there is more useful information in my repository! And explained more in-depth!

Images



An example program is in the Github repository!

Releases
Version 1.0 - Initial release.
Version 2.0 - Parser overhaul.
Version 2.1 - Additional Math Operation Support.
Version 2.2 - Bug Fixes.
Version 2.3 - Bug Fixes with math operations in classes.

Feedback is appreciated.
Regards,
Laurynas.

[pgimeno]

I've tried your example, but since I generally need to use 'dt' in the update function, I added it as a parameter in Main.olua; as a result, the update function no longer existed. Looking at the parsed result, it had created a function called dt, instead of update.

The parser does not handle strings, with many consequences. This string will break the expectations of the parser: "--". and this one too: "The end is near" because it contains the keyword 'end'. Newlines in multi-line strings will get replaced by spaces. Sequences of multiple spaces in a string will be replaced with a single space.

It does not handle --[===[ ... ]===] style comments (or strings, because it doesn't handle strings). It doesn't handle keywords that are not surrounded by spaces at both sides, like function update()end. When I tried that, it froze; I guess it was looking for a matching end that was never found.

As I already hinted in the Super Strict thread, parsers need a lot more care to get them right. Here's an example parser I made just to handle strings and comments (it removes them but you could use something similar to just skip them): https://github.com/minetest-mods/meseco ... f8bca0247c

[lauriszz123]

Thank you for your descriptive comment.

Can I have the file that failed for inspection? I could iron out the issue while having the file. Also, I'm doing test cases for any Lua/Objective Lua code that could occur, I will try to iron out as many issues as I can, I wrote some files that could have potential errors but I'd like some community help as well, any test cases that can or are failing would be greatly appreciated if they were posted.

Also will look into your example listed. Thank you for that. Regex is not my specialty, sadly.

Regards,
Laurynas.

[grump]

Regex is not my specialty, sadly.

Regular expressions and its little brother Lua patterns are not the right tool to implement tokenization of arbitrary code. Just differentiating between code, comments, and strings alone is very difficult to get right with that approach, and leads to messy code, complex patterns and bugs.

A proper lexer/tokenizer that can keep track of nested quotes and brackets, and properly handles escape sequences is easier to write and maintain, and is much less prone to bugs. The key is to look at each character individually instead of matching whole strings against patterns.

[lauriszz123]

Regex is not my specialty, sadly.

Regular expressions and its little brother Lua patterns are not the right tool to implement tokenization of arbitrary code. Just differentiating between code, comments, and strings alone is very difficult to get right with that approach, and leads to messy code, complex patterns and bugs.

A proper lexer/tokenizer that can keep track of nested quotes and brackets, and properly handles escape sequences is easier to write and maintain, and is much less prone to bugs. The key is to look at each character individually instead of matching whole strings against patterns.

Thanks for your comment! I've experimented with tokenizers/parsers/AST's and all of that, I found that doing them in Lua is a little bit slow, compared to what I've done now. It really impacts the API file size, parsing speed ( with loading into the memory ), and functionality ( what I mean by that there is a lot more work to get it working in this state ). How it impacts speed is - it needs to loop through all characters, all identifiers, numbers, strings, and so on. On top of that, the AST needs to be parsed as well. As I don't want to reimplement Lua just to add a few keywords. But, sadly I will need to rethink my decisions. Because this parser is just a prototype, I have a few things up my sleeve and will reimplement them in the upcoming versions.

Again thanks for the comment,
Regards,
Laurynas.

[grump]

How it impacts speed is - it needs to loop through all characters, all identifiers, numbers, strings, and so on.

This point makes little sense to me and it seems miguided. gmatch has to loop through the string as well, and parse the patterns, and allocate state with every call. Not to mention that gmatch/gsub are not even JIT compiled. A properly written tokenizer would certainly be faster, cleaner, and more flexible.

[pgimeno]

Can I have the file that failed for inspection? I could iron out the issue while having the file. Also, I'm doing test cases for any Lua/Objective Lua code that could occur, I will try to iron out as many issues as I can, I wrote some files that could have potential errors but I'd like some community help as well, any test cases that can or are failing would be greatly appreciated if they were posted.

Sure. Take the example in the OP, and replace the update function in classes/Main.olua by any of these:

Code: Select all

-- Error - update does not exist. dt needs to be surrounded by spaces, apparently.
function update(dt)
end

Code: Select all

-- Freezes
function update()end

Code: Select all

-- Believes the -- is a comment.
-- Also if 'end' is exactly at the beginning of the line, it freezes.
function update()
  love.window.setTitle("--")
end

Code: Select all

-- Fails to see the string
function update()
  love.window.setTitle[===[
    the end is near
  ]===]
end

Code: Select all

-- Fails to notice that --[[ is part of the string
function update()
  love.window.setTitle[===[
    --[[
    if only...
    ]]
  ]===]
end

Code: Select all

-- Fails to see the comment, freezes
function update()
  --[===[
    if only...
  ]===]
end

Code: Select all

-- thinks 'end' is a keyword
function update()
  love.window.setTitle("The end is near")
end

Code: Select all

-- removes multiple spaces in string
function update()
  love.window.setTitle("The    TITLE    is this")
end

Also will look into your example listed. Thank you for that. Regex is not my specialty, sadly.

I mostly agree with grump. Lua patterns are simply not powerful enough to parse a regular language, because they lack two fundamental features: subexpressions (grouping) and alternation. I don't agree with him that in general regular expressions are not appropriate for tokenization. Lua's tokens do not make a regular language (because of [===...=[ ... ]===...=]), but if a regular expression engine supports backreferences, it can tokenize Lua.

Anyway, I do agree with him that looping through the input characters is the way to go in Lua (with a finite state machine), because patterns aren't enough. That's what I do in the parser I posted. It's quite fast because it uses string.byte, not string.sub, to check characters, therefore it doesn't need to create temporary strings, which is a slow process.

[4vZEROv]

You can use https://github.com/pygy/LuLPeg to have regex and Pegs.
Also vanilla lua already have everything you want to do oop.

[grump]

if a regular expression engine supports backreferences, it can tokenize Lua.

Sure, it's doable. My point was more that you shouldn't, because those expressions get ugly fast and are difficult to parse for a human that wants to modify the parser.

It's quite fast because it uses string.byte, not string.sub

If you microbenchmark string.byte(i) vs. string.sub(i, i), you'll find that they're basically identical in performance. Garbage isn't an issue either for 256 interned strings.

[ivan]

YACC and Flex also use regular experessions in the lexing phase so yes it is common practice. Regex is probaby slower than a hand written lexer like pgimeno's but regex is much easier to read and modify. Also, you still need a parser to handle the actual grammar, lexing is just the first phase.