Live data from Hacker News

Bog – small, strongly typed, embeddable language

github.com

11–20 of 55 posts

Re: Bog – small, strongly typed, embeddable language

#11
post #8

Pretty interesting. I'm a professional user of Lua, and while I love it, I really get frustrated at a lot of aspects of it, especially how loose the typing is. I've long wished there were more strongly typed alternatives, but just nothing compares to the performance, stability, and quality of documentation of Lua. I'm not sure how I would embed this in a non-Zig project, though.

Have you heard of Teal (https://github.com/teal-language/tl)? It's like typescript for Lua made by Hisham. It also has the concept of declaration files so you can import (and type) existing Lua modules if needed.

Re: Bog – small, strongly typed, embeddable language

#12
post #8

Pretty interesting. I'm a professional user of Lua, and while I love it, I really get frustrated at a lot of aspects of it, especially how loose the typing is. I've long wished there were more strongly typed alternatives, but just nothing compares to the performance, stability, and quality of documentation of Lua. I'm not sure how I would embed this in a non-Zig project, though.

Have you heard of Teal ( https://github.com/teal-language/tl )? It's like typescript for Lua made by Hisham. It also has the concept of declaration files so you can import (and type) existing Lua modules if needed.

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.

Re: Bog – small, strongly typed, embeddable language

#13
post #7

Thank you for posting this. > let {print} = import "std.io" An idea obvious in hindsight that I hadn't thought before - if import returns an environment and let can destructure, then a pattern match can bind an explicit subset of that import. Something like: `(let {print read} (import io) (print (read)))` Further down I find essentially that example (with input instead of read) and destructuring assignment within fun…

Funny, I find this syntax very obtuse: it looks to me like "print" is being defined as, well, the print function, through a very roundabout name collision. What happens if there is a typo and the code says: let {ptint} =... What error message comes up?

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

Re: Bog – small, strongly typed, embeddable language

#14
Somewhat related is yesterday's post about the Cyber programming language, also built on Zig and also embeddable: https://news.ycombinator.com/item?id=34553236

(Not affiliated with either, just can be easy to miss stories on here sometimes, and I figured anyone interesting in Bog might also be interested in Cyber)

Re: Bog – small, strongly typed, embeddable language

#15

Thank you for posting this. > let {print} = import "std.io" An idea obvious in hindsight that I hadn't thought before - if import returns an environment and let can destructure, then a pattern match can bind an explicit subset of that import. Something like: `(let {print read} (import io) (print (read)))` Further down I find essentially that example (with input instead of read) and destructuring assignment within fun…

This is bog standard javascript these days.

Re: Bog – small, strongly typed, embeddable language

#18
post #7

Thank you for posting this. > let {print} = import "std.io" An idea obvious in hindsight that I hadn't thought before - if import returns an environment and let can destructure, then a pattern match can bind an explicit subset of that import. Something like: `(let {print read} (import io) (print (read)))` Further down I find essentially that example (with input instead of read) and destructuring assignment within fun…

Funny, I find this syntax very obtuse: it looks to me like "print" is being defined as, well, the print function, through a very roundabout name collision. What happens if there is a typo and the code says: let {ptint} =... What error message comes up?

"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.

Re: Bog – small, strongly typed, embeddable language

#20

Thought this was statically typed for a moment... Shame. I don't think you need to call out strong typing. Who would make a weakly typed language in 2023?

> Who would make a weakly typed language in 2023

Interactive programming and programming on data (e.g. SQL) both make sense to have weak typing to me.

But yeah I did misread strong typing in this as static typing. Thanks for calling that out.

Post reply on HN