4 ms·

I totally agree about Lua and classes; this is a breath of fresh air. I have played around with Lua for years, and I like it in theory, mainly because it has a

by chubot 12y ago

I totally agree about Lua and classes; this is a breath of fresh air. I have played around with Lua for years, and I like it in theory, mainly because it has a nice implementation. The C API is especially nice (vs say Python). But personally I think the language itself is ugly, and inferior to Python in almost every way. Python's classes are a bit annoying to me, but Lua's idioms for classes are even worse (and I never felt prototypes really lived up to their promise). I could never get myself to write anything more than toys with Lua; it was just cumbersome. Wren looks like a really solid design. I think scripting languages went way too far to the "left" with prototypes and the dynamic behavior of classes (including JS, etc.). This seems a lot more sensible and usable. It looks a bit like Dart (AFAICT), which is probably no coincidence? EDIT: I noticed that the embedding API is not fleshed out yet. Random drive-by ideas/questions: - Are you going to model it after Lua as you did the parser? I don't think that's a bad place to start -- the stack-based model seems strictly superior to dozens of ad hoc methods like Python. And I believe Python itself is a lot cleaner than Perl, Ruby, v8, or the JVM. The Lua authors did a great job with this comparison paper: http://www.jucs.org/jucs_13_6/c_apis_in_extension http://www.jucs.org/jucs_13_6/c_apis_in_extension - I always wanted channels between C/C++ and a scripting language. That is, an idiomatic and supported way of running the scripting language would be in another thread. I think of it as a single-threaded "control plane" in a scripting language, and then multithreaded C/C++ for the "data plane". And you use Go-like channels to communicate between the two. I wrote something like this for Python and multithreaded C++ (which is a nice of making the GIL irrelevant). This can of course be implemented as an optional layer on top of a Lua- or Python-like API. - I've only played around with this a little, but there is a newer CFFI package for Python: https://cffi.readthedocs.org/en/release-0.8/ https://cffi.readthedocs.org/en/release-0.8/ It is a compromise between 1) the "old style" C APIs where you have to write tons of glue, and then it ends up being auto-generated with some tool that nobody understands like SWIG; and 2) the new style like ctypes or LuaJIT where you have to duplicate type information in your source code. If you mess up or the ABI changes then you get crashes. CFFI has a model where you paste in incomplete C declarations and it safely generates a binding, which I think is quite nice. I guess it is a little C-specific. Not sure how it would interact with C++. I think both C and C++ are important use cases.

munificent 12y ago
> It looks a bit like Dart (AFAICT), which is probably no coincidence? Probably more convergent evolution than anything, but there are certainly similarities. :) > Are you going to model it after Lua as you did the parser? Yes, absolutely. My mantra is "when in doubt, do what Lua does", which works surprisingly well. I have so much respect for Ierusalimschy and company. You can see the in-progress API here: https://github.com/munificent/wren/blob/master/include/wren.h https://github.com/munificent/wren/blob/master/include/wren.... > They did a great job with this comparison paper: http://www.jucs.org/jucs_13_6/c_apis_in_extension http://www.jucs.org/jucs_13_6/c_apis_in_extension Oh, man. This is perfect! > I always wanted channels between C/C++ and a scripting language. Wren is deeply built around fibers. It doesn't use the native C stack, so my hope is that it will be pretty easy to be able to suspend the interpreter to switch back to C and then resume it when you go back. All of the mechanism is there, I just have to see how it feels in practice. You can build channels on top of fibers, so I'm really keen to play around with some different concurrency and communication models here and see what they feel like. > I think both C and C++ are important use cases. Me too.
- marktangotango 12y ago
  Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Example, say I have a thread with a wren vm instance running with a bunch of fibers inside, and a fiber calls back to a C function that's blocking (on io say) then this still blocks the entire thread. Seems like there'd have to be a way to integrate with an event loop, and register a fiber with an event (edit or file descriptor/socket). Contemplating this makes me sleepy and grouchy ie it's very abstract, have you given any thought to this use case?
  - munificent 12y ago
    > Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Think of them as a way to organize your program, not a way to optimize it. Fibers let you have multiple independent imperative flows of behavior that you can bounce between without having to return from one in order to get to the other. Instead of always having to organize your behavior in a single rigid stack of "can't do X until done doing Y", you can have as many separate stacks as you want. You can also hook them up to something like asynchronous IO where an IO operation will implicitly park a fiber and let others run. I did that using libuv in my other language Magpie [1]. That's also really nice, but it naturally requires more low level support and has some implications on how fibers are scheduled. In Wren, fibers are explicitly cooperative—you specifically choose which fiber to resume when you suspend one. If you're parking on IO, you need some more implicit logic so the scheduler can automatically pick a fiber to resume. In practice, I think that just means that if all fibers are parked waiting on IO, the scheduler resumes whichever one's IO operation completes first. [1]: http://magpie-lang.org/ http://magpie-lang.org/

by chubot 12y ago

munificent 12y ago

> It looks a bit like Dart (AFAICT), which is probably no coincidence? Probably more convergent evolution than anything, but there are certainly similarities. :) > Are you going to model it after Lua as you did the parser? Yes, absolutely. My mantra is "when in doubt, do what Lua does", which works surprisingly well. I have so much respect for Ierusalimschy and company. You can see the in-progress API here: https://github.com/munificent/wren/blob/master/include/wren.h https://github.com/munificent/wren/blob/master/include/wren.... > They did a great job with this comparison paper: http://www.jucs.org/jucs_13_6/c_apis_in_extension http://www.jucs.org/jucs_13_6/c_apis_in_extension Oh, man. This is perfect! > I always wanted channels between C/C++ and a scripting language. Wren is deeply built around fibers. It doesn't use the native C stack, so my hope is that it will be pretty easy to be able to suspend the interpreter to switch back to C and then resume it when you go back. All of the mechanism is there, I just have to see how it feels in practice. You can build channels on top of fibers, so I'm really keen to play around with some different concurrency and communication models here and see what they feel like. > I think both C and C++ are important use cases. Me too.

marktangotango 12y ago
Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Example, say I have a thread with a wren vm instance running with a bunch of fibers inside, and a fiber calls back to a C function that's blocking (on io say) then this still blocks the entire thread. Seems like there'd have to be a way to integrate with an event loop, and register a fiber with an event (edit or file descriptor/socket). Contemplating this makes me sleepy and grouchy ie it's very abstract, have you given any thought to this use case?
- munificent 12y ago
  > Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Think of them as a way to organize your program, not a way to optimize it. Fibers let you have multiple independent imperative flows of behavior that you can bounce between without having to return from one in order to get to the other. Instead of always having to organize your behavior in a single rigid stack of "can't do X until done doing Y", you can have as many separate stacks as you want. You can also hook them up to something like asynchronous IO where an IO operation will implicitly park a fiber and let others run. I did that using libuv in my other language Magpie [1]. That's also really nice, but it naturally requires more low level support and has some implications on how fibers are scheduled. In Wren, fibers are explicitly cooperative—you specifically choose which fiber to resume when you suspend one. If you're parking on IO, you need some more implicit logic so the scheduler can automatically pick a fiber to resume. In practice, I think that just means that if all fibers are parked waiting on IO, the scheduler resumes whichever one's IO operation completes first. [1]: http://magpie-lang.org/ http://magpie-lang.org/