4 ms·

Author here. Not sure why it was posted, but this (really old) project is basically defunct. I gave github.com/luna/* to the people creating the visual Luna lan

Author here. Not sure why it was posted, but this (really old) project is basically defunct. I gave github.com/luna/* to the people creating the visual Luna language that was on HN recently. Moving it to my account must have caught someone's eye. Anyway it was just a toy project that I never had enough time/motivation to complete. I was inspired by the size of Lua's VM, but deterred by its obscurity (and lack of inline documentation), so my original goal was to create a very clean and minimal VM.

naasking 11y ago
The code looks nice and straightforward, and kudos on actually producing a typed language. IMO, there's too little of that these days. Too bad you didn't get around to implementing context threading, because I would have liked to see a clean and portable implementation, particularly if you had also planned to support TCO. Is the design you had planned documented anywhere?
rurban 11y ago
It's very similar to _why's potion, for which I'm the maintainer now. I added lot's of internal documentation there, but haven't got to add type support (easy, but lof of work) and multi-threading (not easy with this GC). coros, exceptions however are there.
munificent 11y ago
> I was inspired by the size of Lua's VM, but deterred by its obscurity (and lack of inline documentation), so my original goal was to create a very clean and minimal VM. Me too, so I created Wren: https://github.com/munificent/wren https://github.com/munificent/wren It's about the same size as Lua, significantly faster, and much more thoroughly documented. I also like the language itself more — it's object model is more familiar to someone coming from Java/C++/C#/etc. — but that's personal preference. ... heh and then I scroll down and see two people have already mentioned Wren. I guess I'm doing a good job of branding it as the "better documented Lua". :)
- naasking 11y ago
  Interesting language, and looks fairly concise to write. I imagine shoehorning all numbers into doubles makes for slower integer code. Also a shame you included pervasive null. Wren looks straightforward enough that you could have a static type system without losing any expressiveness. Have you considered that?
  - munificent 11y ago
    > I imagine shoehorning all numbers into doubles makes for slower integer code. Maybe, though in a bytecode-compiled, dynamically typed language, my hunch is that using doubles for everything is actually faster. If I had separate integer and float types, all of the arithmetic operators would have do runtime type tests to handle the different combinations and conversions. I could be wrong, though. Either way, only having doubles definitely simplifies the VM. > Also a shame you included pervasive null. Yeah, it doesn't come up too often in practice. Unlike, say, JS, Wren considers it a runtime error to call a function without enough arguments. I'm not a big fan of null, but in a dynamically typed language it's sort of inevitable. It's the result type of a function with no explicit return. > Wren looks straightforward enough that you could have a static type system without losing any expressiveness. Have you considered that? Yes! I'm interested in trying to layer an optional type system on top of it, and I tried to design most of the language and core library such that it's amenable to that. However, designing a type system is really hard, so I don't know how well it'll pan out. Now that the language itself is pretty far along and you can write useful programs in it, I'm hoping to start tinkering with this and see what I can come up with. You can see the first baby steps here: https://github.com/munificent/wrenalyzer https://github.com/munificent/wrenalyzer
    - naasking 11y ago
      > Maybe, though in a bytecode-compiled, dynamically typed language, my hunch is that using doubles for everything is actually faster. If I had separate integer and float types, all of the arithmetic operators would have do runtime type tests to handle the different combinations and conversions. Perhaps. I suppose this dovetails with my preference for static types with optional dynamic behaviour, and not the contrary default which seems to be your position. > I'm interested in trying to layer an optional type system on top of it, and I tried to design most of the language and core library such that it's amenable to that. Cool. I think Wren is simple enough that basic type inference should be straightforward and complete, and anything more difficult just infers a top/'dynamic' type. A trivially correct type inference algorithm then just infers type 'dynamic' everywhere, which recovers Wren's current semantics. Then you incrementally add more specific rules where you can, ie. simple data flow from constants will generate more efficient string, floating point and integer code. That would be enough for a decent speedup on most programs. If you want to type check arbitrary objects (or at least avoid method-not-understood), you can use something like "Type Inference for First-Class Messages with Match-Functions" [1] or the even more general first-class labels [2]. I believe first-class labels are more general than Wren's semantics. [1] http://lambda-the-ultimate.org/node/4808 http://lambda-the-ultimate.org/node/4808 [2] http://lambda-the-ultimate.org/node/174 http://lambda-the-ultimate.org/node/174

naasking 11y ago

The code looks nice and straightforward, and kudos on actually producing a typed language. IMO, there's too little of that these days. Too bad you didn't get around to implementing context threading, because I would have liked to see a clean and portable implementation, particularly if you had also planned to support TCO. Is the design you had planned documented anywhere?

rurban 11y ago

It's very similar to _why's potion, for which I'm the maintainer now. I added lot's of internal documentation there, but haven't got to add type support (easy, but lof of work) and multi-threading (not easy with this GC). coros, exceptions however are there.

munificent 11y ago

> I was inspired by the size of Lua's VM, but deterred by its obscurity (and lack of inline documentation), so my original goal was to create a very clean and minimal VM. Me too, so I created Wren: https://github.com/munificent/wren https://github.com/munificent/wren It's about the same size as Lua, significantly faster, and much more thoroughly documented. I also like the language itself more — it's object model is more familiar to someone coming from Java/C++/C#/etc. — but that's personal preference. ... heh and then I scroll down and see two people have already mentioned Wren. I guess I'm doing a good job of branding it as the "better documented Lua". :)

naasking 11y ago
Interesting language, and looks fairly concise to write. I imagine shoehorning all numbers into doubles makes for slower integer code. Also a shame you included pervasive null. Wren looks straightforward enough that you could have a static type system without losing any expressiveness. Have you considered that?
- munificent 11y ago
  > I imagine shoehorning all numbers into doubles makes for slower integer code. Maybe, though in a bytecode-compiled, dynamically typed language, my hunch is that using doubles for everything is actually faster. If I had separate integer and float types, all of the arithmetic operators would have do runtime type tests to handle the different combinations and conversions. I could be wrong, though. Either way, only having doubles definitely simplifies the VM. > Also a shame you included pervasive null. Yeah, it doesn't come up too often in practice. Unlike, say, JS, Wren considers it a runtime error to call a function without enough arguments. I'm not a big fan of null, but in a dynamically typed language it's sort of inevitable. It's the result type of a function with no explicit return. > Wren looks straightforward enough that you could have a static type system without losing any expressiveness. Have you considered that? Yes! I'm interested in trying to layer an optional type system on top of it, and I tried to design most of the language and core library such that it's amenable to that. However, designing a type system is really hard, so I don't know how well it'll pan out. Now that the language itself is pretty far along and you can write useful programs in it, I'm hoping to start tinkering with this and see what I can come up with. You can see the first baby steps here: https://github.com/munificent/wrenalyzer https://github.com/munificent/wrenalyzer
  - naasking 11y ago
    > Maybe, though in a bytecode-compiled, dynamically typed language, my hunch is that using doubles for everything is actually faster. If I had separate integer and float types, all of the arithmetic operators would have do runtime type tests to handle the different combinations and conversions. Perhaps. I suppose this dovetails with my preference for static types with optional dynamic behaviour, and not the contrary default which seems to be your position. > I'm interested in trying to layer an optional type system on top of it, and I tried to design most of the language and core library such that it's amenable to that. Cool. I think Wren is simple enough that basic type inference should be straightforward and complete, and anything more difficult just infers a top/'dynamic' type. A trivially correct type inference algorithm then just infers type 'dynamic' everywhere, which recovers Wren's current semantics. Then you incrementally add more specific rules where you can, ie. simple data flow from constants will generate more efficient string, floating point and integer code. That would be enough for a decent speedup on most programs. If you want to type check arbitrary objects (or at least avoid method-not-understood), you can use something like "Type Inference for First-Class Messages with Match-Functions" [1] or the even more general first-class labels [2]. I believe first-class labels are more general than Wren's semantics. [1] http://lambda-the-ultimate.org/node/4808 http://lambda-the-ultimate.org/node/4808 [2] http://lambda-the-ultimate.org/node/174 http://lambda-the-ultimate.org/node/174