Project alive?

[DAddYE]

Project alive?

[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!