From dc1c5fc3acfc6e381220be73162e6e41abb76e19 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Fri, 26 Feb 2021 22:25:35 -0500 Subject: Mention that tacit exports weaken encapsulation --- commentary/problems.md | 3 +++ docs/commentary/problems.html | 2 ++ 2 files changed, 5 insertions(+) diff --git a/commentary/problems.md b/commentary/problems.md index 017d680b..c211954a 100644 --- a/commentary/problems.md +++ b/commentary/problems.md @@ -184,6 +184,9 @@ Select chooses whether the left argument maps to right argument axes or selects ### Unclear primitive names Blanket issue for names that I don't find informative: "Solo", "Bins", "Find", and "Group". +### Tacit exports can leak data +One of the nice facets of BQN's module system is that it provides perfect encapsulation: if you have variables `a` and `b` in a namespace (or closure) initialized so that `a≤b`, and all exported operations maintain the property that `a≤b`, then that property will always be true. Well, not quite: if you define, say `Inc ⇐ IncA ⊣ IncB` to increase the values of both `a` and `b` by `𝕩`, then `Inc` maintains `a≤b`, but `IncA` doesn't—and it can be extracted with `•Decompose`. This isn't too serious because it sounds impossible to do accidentally, and it's easy to protect against. + ### Strands go left to right This is the best ordering, since it's consistent with `⟨⋄⟩` lists. And code in a strand probably shouldn't have side effects anyway. Still, it's an odd little tack-on to say separators *and strands* go left to right, and it complicates the implementation a little. diff --git a/docs/commentary/problems.html b/docs/commentary/problems.html index acb0839b..fc90bc3f 100644 --- a/docs/commentary/problems.html +++ b/docs/commentary/problems.html @@ -137,6 +137,8 @@

Select chooses whether the left argument maps to right argument axes or selects from the first axis only based on its depth. Without prototypes an empty array has depth 1, so it selects no major cells. However, it could also select from no axes (a no-op) and in some contexts the other behavior would be surprising.

Unclear primitive names

Blanket issue for names that I don't find informative: "Solo", "Bins", "Find", and "Group".

+

Tacit exports can leak data

+

One of the nice facets of BQN's module system is that it provides perfect encapsulation: if you have variables a and b in a namespace (or closure) initialized so that a≤b, and all exported operations maintain the property that a≤b, then that property will always be true. Well, not quite: if you define, say Inc ⇐ IncA ⊣ IncB to increase the values of both a and b by 𝕩, then Inc maintains a≤b, but IncA doesn't—and it can be extracted with •Decompose. This isn't too serious because it sounds impossible to do accidentally, and it's easy to protect against.

Strands go left to right

This is the best ordering, since it's consistent with ⟨⋄⟩ lists. And code in a strand probably shouldn't have side effects anyway. Still, it's an odd little tack-on to say separators and strands go left to right, and it complicates the implementation a little.

Primitive name capitalization

-- cgit v1.2.3