Bog – small, strongly typed, embeddable language

Nice, thanks. Looks pretty reasonable, but I'd really have to learn some zig myself to be fully comfortable using it, I think.

I haven't, but I might have to do a lot of work to get it working, as my typical use of Lua is deeply embedded and customized, and doesn't allow any filesystem access. I will definitely look into that, though, thank you. The only real Lua dialect I'm familiar with in that area is Moonscript.

Teal only type checks when run from the command line though, which isn't the best when you want to embed Lua. At least thats what my reading of the docs says, I'd be happy if I'm wrong. But reading the docs now, it doesn't seem to say that any more - maybe its changed recently?

Edit: Oh yes it's still like that 'When loading and running the Teal module from Lua, there is no type checking! Type checking will only happen when you run tl check or load a program with tl run.' from https://github.com/teal-language/tl/blob/master/docs/tutoria...

We use a heavily stripped and sandboxed Lua interpreter for user scripts in a monitoring system. The initial approach was going to be WebAssembly, but that didn't pan out for a couple reasons.

Much of the functionally has been wrapped or customized to disallow any system access that doesn't go through an access control layer, including for require, and disallowing catching certain errors with pcall and through coroutines. Anything that could feasibly break the sandbox is also removed, like the debug package, and the ability to load bytecode (text sources only). The actual Lua sources are 100% vanilla, though we complete it with C++ to be compatible with the rest of the codebase.

> Something I hate about about c is that you don't know where the hell somefunc() came from.

I think you mean something you hate about not using an IDE with the language. One can do `from onoz import *` in python and Java to have a similar "wait, where did do_magic() come from?" experience, and then Scala will see your wildcard import and raise you implicit methods, which can die in a raging fire tornado

This is true that there is no language feature to enforce this. But this can be worked around by enforcing naming functions with adequate prefixes, which is a very common approach, if not a best practice.

Well I can't test it in bog, but TypeScript allows exactly this syntax and it will give you an error like "Property ptint does not exist on type ..."

One would imagine that

  let {print} = import "std.io"

is equivalent to

  let print = (import "std.io").print

"Obtuse" is maybe not the word you were looking for. Opaque perhaps?

This kind of destructuring syntax is common in many newish languages -- Rust, Clojure, newer flavors of JS, Typescript, etc -- and becomes second nature pretty quickly. What you're seeing is really two things: first that you can pull apart a map as part of assignment, and second that there's sugar to name the variable after the map key.

In JS, you could write:

     const { foo: bar } = something
     

And that's sugar for

     const bar = something.foo

At the same time, JS many other languages have pervasive support for the idea that often you want the same name for a variable as the map key where you're going to use it. So, e.g.

     const mapOfFoo = { foo }

is equivalent to

     const mapOfFoo = { foo: foo }

Combining these things, you get:

    const { foo } = something

Equivalent to

    const foo = something.foo

i.e. the variable/property auto-aliasing works in the destructure too. When you consider that you are importing a big object with a bunch of fields and functions hung off of it, it becomes natural for that to work the same way:

    import { foo } from "someplace"

I'd argue that it's not actually opaque, let alone obtuse; it's merely unfamiliar because it's (I'm guessing) a combination of unfamiliar syntactical motifs. But as you get more familiar with that kind of syntax, you'll find it natural, and would be surprised if, say, it worked for regular objects but not in imports. When I picked up Rust, for example, I found myself right at home with it (same for the pattern-matching assignment stuff, which feels very similar to Clojure's).

As for errors, you'd get the same error as in the desugared version: ptint is not a property on the object it's pulling apart.

It's not roundabout. Namespaces in many languages are simply dictionaries/mappings of strings to objects, with the restriction that the strings must conform to a variable name standard.

There's not much difference between `obj.attr` and `obj['attr']`.

No, you're thinking of `destructuring`. CommonJS was "just" a common format for defining/importing modules in a NodeJS environment (via `module.exports` and `require`), eventually being used for packaging frontend "applications" as well, popularized by Browserify.

To expand, the following was common before destructuring but with CommonJS:

    var some_func= require('some_module').some_func

Which, as you know, would probably usually be done like this today, where we have destructuring:

    let {some_func} = require('some_module')

I read that as "Yes, Bog does formatted strings", and appreciate the density.

ugh, yes, I mean the colon

People literally do that all the time! Godot does it, Unity does it...