3 ms·

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

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?

hmry 4y ago
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
icambron 4y ago
"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.
xapata 4y ago
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']`.

hmry 4y ago

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

icambron 4y ago

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

xapata 4y ago

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']`.