From 2b1ea7f5d9cd546e9d601ec3cda2b5bd8b5b92e4 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Mon, 19 Oct 2020 22:58:44 -0400 Subject: Reassess control flow problem severity --- docs/problems.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/problems.html') diff --git a/docs/problems.html b/docs/problems.html index f67eb031..f0e86e48 100644 --- a/docs/problems.html +++ b/docs/problems.html @@ -11,8 +11,6 @@

A pretty fundamental problem with dynamically-typed array languages. Prototypes are intended to solve it, but they don't really. It doesn't help that the notion of type is fluid: elements of an array in one moment can be axis lengths in the next; did the numeric value go from not being type information to being type information? Inferred type might help here, particularly the ability of one part of the program to ask another part for type information during compilation. But that needs to be specified if programmers are going to rely on it, which sounds difficult.

Incoherent monad-dyad builtin pairs

BQN inherits the functions +×⌊⌈|, and adds the functions ∧∨<>≠≡≢↕⍷, that are only paired for their glyphs and not for any other reason (that is, both function valences match the symbol but they don't match with each other). I find there are just not enough good glyphs to separate all of these out, but I'm sure the pairings could be improved.

-

Control flow substitutes have awkward syntax

-

At the moment BQN has no control structures, instead preferring modifiers, function recursion, and headers. When working with pure functions, these can be better than control structures. For more imperative programming they're a lot worse. Given that blocks without headers also end up with an unexpected type if you don't use the inputs, it's safe to say BQN isn't great for imperative programming overall. But that's a big loss, and it's very much worth fixing if it can be done with something like a single control structure that conditionally or repeatedly executes an immediate block.

Glyphs are hard to type

There's been a lot of work done on this. Still there, still a problem. On the other hand, glyphs are easy to read, and write by hand!

Tacit and one-line functions are hard to debug

@@ -23,6 +21,8 @@

There are a lot of standard functions and I don't want to use separate primitives or a menu-style primitive like APL Circle for them. You can define all the functions eventually if you use complex exponential and take real and imaginary parts and inverses, but this doesn't sound well-suited for implementation. And there should be a math library that gives you the standard functions with normal names, but how will it be implemented?

Right-to-left multi-line functions go upwards

If you include multiple multi-line functions in what would otherwise be a one-liner, the flow in each function goes top to bottom but the functions are executed bottom to top. I think the fix here is to just say give your functions names and don't do this.

+

Control flow substitutes have awkward syntax

+

At the moment BQN has no control structures, instead preferring modifiers, function recursion, and headers. When working with pure functions, these can be better than control structures. For more imperative programming they're a lot worse. However, predefined functions acting on functions can cover a lot of ground for the imperative programmer; see Control flow in BQN.

Hard to search part of an array or in a different order

This includes index-of-last, and searching starting at a particular index, when the desired result indices are to the array to be seached before it is modified. Given indices i into an array 𝕨 (for example ⌽↕≠𝕨 or a+↕b), this section can be searched with (i∾≠𝕨)⊏˜(i⊏𝕨)⊐𝕩. But this is clunky and difficult for the implementation to optimize.

Subtraction, division, and span are backwards

-- cgit v1.2.3