Project alive?

[DAddYE]

Seeing Shine I was wondering if you plan continue the development on this project.

I'm pretty interested in a ES6 like syntax (the one drafted) even without compatibility on ES4, I think is well designed for this kind of languages.

If you are still interested in this project please put some example, some todos and I'll try to contribute.

[richardhundt]

On 4/7/14 9:55 PM, DAddYE wrote:

Seeing Shine I was wondering if you plan continue the development on this project.

I'm pretty interested in a ES6 like syntax (the one drafted) even without compatibility on ES4, I think is well designed for this kind of languages.

If you are still interested in this project please put some example, some todos and I'll try to contribute.

Melody is the precursor of Shine. I wrote most of it in week while on holiday, so it's very rough. One language right now is enough for me to work on, though, so yeah, Melody isn't happening any time soon.

I could answer specific questions, but you'd basically be on your own. I just don't have the bandwidth to get into it again.

For examples, you can check out the code and run:

./melody test/class.js and see what it does. It already has many of the features coming up in harmony.

Also the bytecode generation isn't perfect, which is why I dropped in in Shine and switched to TvmJIT. Francesco made a derivative of my bytecode generator here [1], so I'd recommend using that instead.

It shouldn't be too hard to swap out the code generation, but it won't be a drop-in replacement. The AST on the LuaJIT side is a little different in Francesco's version.

Then you'll find that the way the grammar is defined in the parser is going to bite with exponentially increasing parse times for deeply nested expressions, but that's not hard to fix either once you understand where the complexity comes from (these are all problems I've fixed in Shine since, but they're still lurking in Melody's code).

If it were me, I'd start with the Shine code base and change that to look more like JavaScript. You get a lot of things for free (event loop, generators, destructuring assignment, etc.)

Of course, there's still JavaScript specific semantics you'll bump into

• binding this correctly, hoisting all variable and function declarations to the top of the scope, the stupid arguments object, apply and call... the list goes on. It basically means a completely different run-time environment to Lua.

[1] https://github.com/franko/luajit-lang-toolkit

[DAddYE]

Thanks for the fully explanation.

Now it makes more sense to me trying to use and then contribute in Shine.

The reason why I was looking for something like a mix between lua/es6 is because es6 fits very well (in terms of syntax) with the reactor pattern and so callbacks. I never though for a while adding what I define oddities of the old js school like this, arguments crazy hoising, == or === etc...

See it as a modern interpretation of ES6 in the Lua aim: keep it simple and fast.

After many years working with ruby, js and many others I found that where you need a lot callbacks an indented syntax (coffee/python) or a braced one {} fits a bit better than function()...end.

I'll try to work a little bit with Shine and see how it fits since my final aim is to rewrite my (co-founded) framework padrino on a fasted vm an obviously on a nice language.

If you'll be open to suggestion and we both share the same view I'll be more than happy to be part of the project.

[richardhundt]

On 4/7/14 11:21 PM, DAddYE wrote:

See it as a modern interpretation of ES6 in the Lua aim: keep it simple and fast.

After many years working with ruby, js and many others I found that where you need a lot callbacks an indented syntax (coffee/python) or a braced one |{}| fits a bit better than |function()...end|.

The cool thing about Lua is that you actually don't need callbacks because you have coroutines. As an example, in ./sample/tcp_server.shn, there aren't any callbacks. Each client connection spawns a coroutine.

When you say socket.read(), if there's no data available, your current coroutine will simply be suspended, to be resumed by the event loop when the socket is readable. By the time socket.read() returns, you have your data and you actually have no way of telling whether it happened immediately or after a minute.

This is also fast. In ./sample/httpd.shn there's a really simple http server which I benchmarked against an equivalent node.js implementation.

With 1000 concurrent connections, node.js managed 11k req/sec using 23MB RAM. Shine did 15k req/sec using 8MB... and no callbacks. The callbacks are hidden behind fiber-aware semaphores and there's still an event loop underneath. You just don't see it.

So if your goal is to make reactors less ugly, then my response to that is why even bother with them at all? No matter how pretty your callback syntax, as your application grows, you'll still end up in asynchronous callback hell where there's no clear linear flow to your application.

About the best you can do, if you absolutely must have callbacks, is hide them behind futures and promises.

I'll try to work a little bit with Shine and see how it fits since my final aim is to rewrite my (co-founded) framework padrino https://github.com/padrino/padrino-framework on a fasted vm an obviously on a nice language.

If you'll be open to suggestion and we both share the same view I'll be more than happy to be part of the project.

I've started working on a web framework in Shine. It's early days, but sure, I can put it up on github and you can dive in. It'll be external to the core language, but having a real world project like that will help iron out the wrinkles. I'll need a day or two to finish off the basic layout, and then I'll throw it up and let you know.

In the meantime I've put up a gist of the HTTPRouter [1], and this is how you'd use it (it's actually wrapped inside a controller):

routes = HTTPRouter()
routes.add "GET", '/foo/:bar', (...) =>
   print "here: ", ...
end

route, params, query = routes.match "GET", '/foo/42?hello=world'
for k, v in params do
   print k, v
end

The reason I thought I'd show you is because it composes LPeg patterns uses them as a matching engine. So the syntax looks a bit funky, but it's really short and really fast.

[1] https://gist.github.com/richardhundt/10065296

[DAddYE]

the builtin lpeg is indeed amazing. Thanks for sharing the example, I'm starting to play a bit with it ;)

In the meanwhile that (isn't callback I know) is the effect that happens quite often and I'd like to avoid.

I handmade an indented variant so you can see the difference: https://gist.github.com/DAddYE/28af3866423efe772aa5

[richardhundt]

I've made a rough version with curly syntax:

https://github.com/richardhundt/shine/tree/alt-syntax

I've spent all of 10 minutes on it, so don't expect it to be perfect. It also doesn't compile the libraries, because I'm not going to port them all to the new syntax just for a demo.

This is what it looks like:

class Point {
   self(x : Number, y : Number) {
      self.x = x
      self.y = y
   }
}

var p = Point(1, 2)

print p.x, p.y

if (1 == 2) {
   print "funny"
}
else if (1 == 1) {
   print "good"
}
else {
   print "huh?"
}

The reason I've done this is to show you how trivial it is to change syntax, that's why it's far more useful and interesting for me to discuss semantics.

Have fun

[DAddYE]

Awesome! I'll play a bit on it!