From 673de1c627a2046123e1693e9e6508399a028508 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Sat, 3 Oct 2020 16:38:35 -0400 Subject: Write files directly from md.bqn, not gendocs (removes trailing empty lines) --- docs/doc/based.html | 1 - docs/doc/block.html | 1 - docs/doc/context.html | 1 - docs/doc/couple.html | 1 - docs/doc/depth.html | 1 - docs/doc/extensions.html | 1 - docs/doc/fromDyalog.html | 1 - docs/doc/functional.html | 1 - docs/doc/glossary.html | 1 - docs/doc/group.html | 1 - docs/doc/index.html | 1 - docs/doc/indices.html | 1 - docs/doc/join.html | 1 - docs/doc/leading.html | 1 - docs/doc/logic.html | 1 - docs/doc/prefixes.html | 1 - docs/doc/primitive.html | 1 - docs/doc/shift.html | 1 - docs/doc/syntax.html | 1 - docs/doc/train.html | 1 - docs/doc/transpose.html | 1 - docs/doc/types.html | 1 - docs/doc/windows.html | 1 - docs/implementation/codfns.html | 1 - docs/implementation/index.html | 1 - docs/implementation/vm.html | 1 - docs/index.html | 1 - docs/problems.html | 1 - docs/running.html | 1 - docs/spec/evaluate.html | 1 - docs/spec/grammar.html | 1 - docs/spec/index.html | 1 - docs/spec/inferred.html | 1 - docs/spec/literal.html | 1 - docs/spec/scope.html | 1 - docs/spec/token.html | 1 - docs/spec/types.html | 1 - docs/tutorial/expression.html | 1 - docs/tutorial/index.html | 1 - docs/tutorial/list.html | 1 - 40 files changed, 40 deletions(-) (limited to 'docs') diff --git a/docs/doc/based.html b/docs/doc/based.html index 2389481b..c0021093 100644 --- a/docs/doc/based.html +++ b/docs/doc/based.html @@ -49,4 +49,3 @@

The boxed array model of SHARP APL, A+, and J is an inductive system like BQN's. But this model uses arrays as the base case: numeric and character arrays are the simplest kind of data allowed, and "a number" means a rank-0 numeric array. The inductive step is the array of boxes; as with numbers "a box" is simply a rank-0 array of boxes.

Numeric and character arrays in this system have depth 0. In general these correspond to arrays of depth 1 in BQN, but because there's no lower depth they are also used where BQN atoms would appear. For example, both Shape ($) and Length (#) return depth-0 results in J. For an array a with rank at least 1, the length #a is exactly [/ $ a, while the identical BQN code ⊣˝ ≢ a returns not ≠ a but < ≠ a. Like the nested model, the boxed model can hide depth issues that occur at lower depths but generally reveals them at higher depths.

The boundary at depth 0 will tend to cause inconsistencies and confusion in any array language, and boxed array languages push this boundary up a level. This leads to the programmer spending more effort managing boxes: for example, to reverse each list in a list of lists, the programmer can use reverse under open, |. &. >. But to find the lengths of each of these lists, # &. > would yield a boxed list, which is usually not wanted, so # @ > is needed instead. BQN shows that a system that doesn't require these distinctions is possible, as a BQN programmer would use ⌽¨ and ≠¨.

- diff --git a/docs/doc/block.html b/docs/doc/block.html index 5aae039f..24857cfe 100644 --- a/docs/doc/block.html +++ b/docs/doc/block.html @@ -211,4 +211,3 @@

Returns

This feature is not yet included in any BQN implementation.

The glyph → indicates an early return from a block. It must be preceded either by one of the self-reference special names 𝕊 or 𝕣 or by an internal name for a containing block. The combination of name and return token—like F→, let's say—is a function that returns from the current instance of the indicated block. If that instance has already returned, then it instead results in an error.

- diff --git a/docs/doc/context.html b/docs/doc/context.html index a46a4659..1b5e949c 100644 --- a/docs/doc/context.html +++ b/docs/doc/context.html @@ -140,4 +140,3 @@

Other mixes of roles are generally not useful. While a combination such as treating a function as a modifier is allowed, attempting to apply it to an operand will fail. Only a 1-modifier can be applied as a 1-modifier and only a 2-modifier can be applied as a 2-modifier. Only a function or data can be applied as a function.

It's also worth noting that a subject may unexpectedly be a function! For example, the result of 𝕨˜𝕩 may not always be 𝕨. 𝕨˜𝕩 is exactly identical to 𝕎˜𝕩, which gives 𝕩𝕎𝕩. If 𝕎 is a number, character, or array, that's the same as 𝕨, but if it is a function, then it will be applied.

The primary way to change the role of a value in BQN is to use a name, including one of the special names for inputs to a brace function or modifier. In particular, you can use {𝔽} to convert a subject operand into a function. Converting a function to a subject is more difficult. Often an array of functions is wanted, in which case they can be stranded together; otherwise it's probably best to give the function a name. Picking a function out of a list, for example ⊑⟨+⟩, will give it as a subject.

- diff --git a/docs/doc/couple.html b/docs/doc/couple.html index 69f85bab..7aa3779f 100644 --- a/docs/doc/couple.html +++ b/docs/doc/couple.html @@ -85,4 +85,3 @@

Definitions

As discussed above, ≍ is equivalent to >{⟨𝕩⟩;⟨𝕨,𝕩⟩}. To complete the picture we should describe Merge fully. Merge is defined on an array argument 𝕩 such that there's some shape s satisfying ∧´⥊(s≡≢)¨𝕩. If 𝕩 is empty then any shape satisfies this expression; s should be chosen based on known type information for 𝕩 or otherwise assumed to be ⟨⟩. If s is empty then 𝕩 is allowed to contain atoms as well as unit arrays, and these will be implicitly promoted to arrays by the ⊑ indexing used later. We construct the result by combining the outer and inner axes of the argument with Table; since the outer axes come first they must correspond to the left argument and the inner axes must correspond to the right argument. 𝕩 is a natural choice of left argument, and because no concrete array can be used, the right argument will be ↕s, the array of indices into any element of 𝕩. To get the appropriate element corresponding to a particular choice of index and element of 𝕩 we should select using that index. The result of Merge is 𝕩⊑˜⌜↕s.

Given this definition we can also describe Rank (⎉) in terms of Each (¨) and the simpler monadic function Enclose-Rank <⎉k. We assume effective ranks j for 𝕨 (if present) and k for 𝕩 have been computed. Then the correspondence is 𝕨F⎉k𝕩 ←→ >(<⎉j𝕨)F¨(<⎉k𝕩).

- diff --git a/docs/doc/depth.html b/docs/doc/depth.html index d67ce4ed..5e12766b 100644 --- a/docs/doc/depth.html +++ b/docs/doc/depth.html @@ -139,4 +139,3 @@ ↗️
    ≠⚇1 ⟨1,⟨2,⟨3,4⟩⟩,⟨5,⟨6,7⟩,⟨8,9,10⟩⟩,⟨11,12⟩⟩
 ⟨ 1 ⟨ 1 2 ⟩ ⟨ 1 2 3 ⟩ 2 ⟩
- diff --git a/docs/doc/extensions.html b/docs/doc/extensions.html index e781194f..08013bc6 100644 --- a/docs/doc/extensions.html +++ b/docs/doc/extensions.html @@ -36,4 +36,3 @@

Sometimes it is useful to have a mutable type, particularly if a part of the program should maintain its own state over the course of execution. The closures required as part of a complete lexical scoping implementation actually allow something like this. If a function defines and returns an explicit function, then that function can read and change variables in its environment. As the environment includes the scope created to execute the outer function, calling the outer function creates a mutable environment that can be indirectly accessed through the returned function.

A namespace would allow such an environment to be directly accessed and manipulated. While it's possible there would be facilities to create a namespace, a simpler mechanism is simply to add a primitive that returns the current scope as a variable. This scope would then behave the same way as a returned function's environment, and would allow member access by a dot-like syntax.

A symbol is a variable representing a name in the program. Symbols would make it easier to interact with namespaces dynamically.

- diff --git a/docs/doc/fromDyalog.html b/docs/doc/fromDyalog.html index aa53a768..6486b317 100644 --- a/docs/doc/fromDyalog.html +++ b/docs/doc/fromDyalog.html @@ -270,4 +270,3 @@ f& Nothing yet - diff --git a/docs/doc/functional.html b/docs/doc/functional.html index a2902fa1..269d0040 100644 --- a/docs/doc/functional.html +++ b/docs/doc/functional.html @@ -76,4 +76,3 @@ (2⊸|)◶⟨÷⟜2,1+3×⊢⟩⍟(↕10) 6 ⟨ 6 3 10 5 16 8 4 2 1 4 ⟩ - diff --git a/docs/doc/glossary.html b/docs/doc/glossary.html index f8d2ded0..526d028c 100644 --- a/docs/doc/glossary.html +++ b/docs/doc/glossary.html @@ -142,4 +142,3 @@
  • Body: One sequence of statements in a block. Bodies, possibly preceded by headers, are separated by semicolons ;.
  • Tacit: Code that defines functions or modifiers without using blocks.
    • - diff --git a/docs/doc/group.html b/docs/doc/group.html index 9b74f0f6..0087d70b 100644 --- a/docs/doc/group.html +++ b/docs/doc/group.html @@ -154,4 +154,3 @@ ' '((¬-˜⊢×·+`»⊸>)∘≠⊔⊢)" string with spaces " # Slightly shorter ⟨ "string" "with" "spaces" ⟩ - diff --git a/docs/doc/index.html b/docs/doc/index.html index aa65dbee..67a1d9c5 100644 --- a/docs/doc/index.html +++ b/docs/doc/index.html @@ -43,4 +43,3 @@ - diff --git a/docs/doc/indices.html b/docs/doc/indices.html index b50cd571..24d19600 100644 --- a/docs/doc/indices.html +++ b/docs/doc/indices.html @@ -102,4 +102,3 @@

    The most interesting feature would be that ⊏ could still allow a nested left argument. In this case each element of the left argument would be an array with row indices as before. However, each row can now index along multiple axes, allowing some adjacent axes to be dependent while others remain independent. This nicely unifies scatter-point and per-axis selection, and allows a mix of the two. However, it doesn't allow total freedom, as non-adjacent axes can't be combined except by also mixing in all axes in between.

    Group (⊔) could accept the same index format for its index argument. Each depth-1 array in the left argument would correspond to multiple axes in the outer result array, but only a single axis in the argument and inner arrays. Because the ravel ordering of indices must be used to order cells of inner arrays, this modification is not quite as clean as the change to Select. It's also not so clearly useful, as the same results can be obtained by using atomic indices and reshaping the result.

    Overall it seems to me that the main use of cell indices of the type discussed here is for the Select primitive, and the other cases are somewhat contrived an awkward. So I've chosen not to support it in BQN at all.

    - diff --git a/docs/doc/join.html b/docs/doc/join.html index aa2637dd..50defc8a 100644 --- a/docs/doc/join.html +++ b/docs/doc/join.html @@ -42,4 +42,3 @@

    Join has fairly strict requirements on the shapes of its argument elements—although less strict than those of Merge, which requires they all have identical shape. Suppose the argument to Join has rank m. Each of its elements must have the same rank, n, which is at least m. The trailing shapes m↓⟜≢¨𝕩 must all be identical (the trailing shape m↓≢∾𝕩 of the result will match these shapes as well). The other entries in the leading shapes need not be the same, but the shape of an element along a particular axis must depend only on the location of the element along that axis in the full array. For a list argument this imposes no restriction, since the one leading shape element is allowed to depend on position along the only axis. But for higher ranks the structure quickly becomes more rigid.

    To state this requirement more formally in BQN, we say that there is some list s of lists of lengths, so that (≢¨s)≡≢𝕩. We require element i⊑𝕩 to have shape i⊑¨s. Then the first m axes of the result are +´¨s.

    - diff --git a/docs/doc/leading.html b/docs/doc/leading.html index b96c2d9a..108b9d63 100644 --- a/docs/doc/leading.html +++ b/docs/doc/leading.html @@ -224,4 +224,3 @@

    For all of these functions but Find, the argument to search through is treated as a list of its major cells. It is the rank of these major cells—let's call this rank c—that determines how the other argument is treated. That argument must have rank at least c, and it is treated as an array of c-cells. For example, if the left argument to ⍋ is a matrix, then each 1-cell or row of the right argument is treated independently, and each one yields one number in the result: a 0-cell. The result rank of ⍋ is always 𝕨¬○=𝕩.

    - diff --git a/docs/doc/logic.html b/docs/doc/logic.html index 0ede46e7..40aa5906 100644 --- a/docs/doc/logic.html +++ b/docs/doc/logic.html @@ -44,4 +44,3 @@

    It's common to apply ∧´ or ∨´ to a list (checking whether all elements are true and whether any are true, respectively), and so it's important for extensions to And and Or to share their identity element. Minimum and Maximum do match And and Or when restricted to booleans, but they have different identity elements. It would be dangerous to use Maximum to check whether any element of a list is true because >⌈´⟨⟩ yields ¯∞ instead of 0—a bug waiting to happen. Always using 0 as a left argument to ⌈´ fixes this problem but requires more work from the programmer, making errors more likely.

    It is easy to prove that the bilinear extensions have the identity elements we want. Of course 1∧x is 1×x, or x, and 0∨x is 0×⌾¬x, or ¬1׬x, giving ¬¬x or x again. Both functions are commutative, so these identities are double-sided.

    Other logical identities do not necessarily hold. For example, in boolean logic And distributes over Or and vice-versa: a∧b∨c ←→ (a∧b)∨(a∧c). But substituting × for ∧ and +-× for ∨ we find that the left hand side is (a×b)+(a×c)+(a×b×c) while the right gives (a×b)+(a×c)+(a×b×a×c). These are equivalent for arbitrary b and c only if a=a×a, that is, a is 0 or 1. In terms of probabilities the difference when a is not boolean is caused by failure of independence. On the left hand side, the two arguments of every logical function are independent. On the right hand side, each pair of arguments to ∧ are independent, but the two arguments to ∨, a∧b and a∧c, are not. The relationship between these arguments means that logical equivalences no longer apply.

    - diff --git a/docs/doc/prefixes.html b/docs/doc/prefixes.html index 9aa3dd20..21bbeff7 100644 --- a/docs/doc/prefixes.html +++ b/docs/doc/prefixes.html @@ -212,4 +212,3 @@ ┘ ┘ ┘ ┘ - diff --git a/docs/doc/primitive.html b/docs/doc/primitive.html index 4ce6a7c4..37d8e08c 100644 --- a/docs/doc/primitive.html +++ b/docs/doc/primitive.html @@ -353,4 +353,3 @@ - diff --git a/docs/doc/shift.html b/docs/doc/shift.html index f96661d1..0ca9f825 100644 --- a/docs/doc/shift.html +++ b/docs/doc/shift.html @@ -127,4 +127,3 @@

    In any instance of » or «, 𝕩 must have rank at least 1.

    For a dyadic shift function, 𝕨 must be Join-compatible with 𝕩 (that is, 𝕨∾𝕩 completes without error) and cannot have greater rank than 𝕩. Then Shift Before (») is {(≠𝕩)↑𝕨∾𝕩} and Shift After («) is {(-≠𝕩)↑𝕩∾𝕨}

    When called monadically, the default argument is a cell of fills 1↑0↑𝕩. That is, Nudge (») is (1↑0↑⊢)⊸» and Nudge Back («) is (1↑0↑⊢)⊸«. This default argument always satisfies the compatibility requirement above and so the only conditions for nudge are that 𝕩 has rank at least 1 and has a fill element.

    - diff --git a/docs/doc/syntax.html b/docs/doc/syntax.html index 427f05c9..0a6aab58 100644 --- a/docs/doc/syntax.html +++ b/docs/doc/syntax.html @@ -156,4 +156,3 @@

    Blocks are written with curly braces {} and can be used to group expressions or define functions and modifiers. The contents are simply a sequence of expressions, where each is evaluated and the result of the last is returned in order to evaluate the block. This result can have any value, and its syntactic role in the calling context is determined by the normal rules: functions return subjects and modifiers return functions. Blocks have lexical scope.

    The special names 𝕨 and 𝕩, which stand for arguments, and 𝕗 and 𝕘, which stand for operands, are available inside curly braces. Like ordinary names, the lowercase forms indicate subjects and the uppercase forms 𝕎𝕏𝔽𝔾 indicate functions. The type and syntactic role of the block is determined by its contents: a 2-modifier contains 𝕘, a 1-modifier contains 𝕗 but not 𝕘, and a function contains neither but does have one of 𝕨𝕩𝕤𝕎𝕏𝕊. If no special names are present the block is an immediate block and is evaluated as soon as it appears, with the result having a subject role.

    A modifier can be evaluated twice: once when passed operands and again when the resulting function is passed arguments. If it contains 𝕨 or 𝕩, the first evaluation simply remembers the operands, and the contents will be executed only on the second evaluation, when the arguments are available. If it doesn't contain these, then the contents are executed on the first evaluation and the result is treated as a function.

    - diff --git a/docs/doc/train.html b/docs/doc/train.html index 63ae731b..c7f9eeea 100644 --- a/docs/doc/train.html +++ b/docs/doc/train.html @@ -94,4 +94,3 @@ ⟨ 0 2 3 4 ⟩

    In our example, there aren't enough of these functions to really be cumbersome. If ⍷∘∧ is a common combination in a particular program, then the train ⍷∘∧| will be more visually consistent and make it easier to use a utility function for ⍷∘∧ if that's wanted in the future.

    - diff --git a/docs/doc/transpose.html b/docs/doc/transpose.html index b7ecac6d..0c49210f 100644 --- a/docs/doc/transpose.html +++ b/docs/doc/transpose.html @@ -90,4 +90,3 @@

    Monadic transpose is identical to (=-1˙)⊸⍉, except that if the argument is a unit it is returned unchanged rather than giving an error.

    An atom right argument to dyadic Transpose is always enclosed to get an array before doing anything else.

    In dyadic Transpose, the left argument is a number or numeric array of rank 1 or less, and 𝕨≤○≠≢𝕩. Define the result rank r←(=𝕩)-+´¬∊𝕨 to be the argument rank minus the number of duplicate entries in the left argument. We require ∧´𝕨<r. Bring 𝕨 to full length by appending the missing indices: 𝕨∾↩𝕨(¬∘∊˜/⊢)↕r. Now the result shape is defined to be ⌊´¨𝕨⊔≢𝕩. Element i⊑z of the result z is element (𝕨⊏i)⊑𝕩 of the argument.

    - diff --git a/docs/doc/types.html b/docs/doc/types.html index 258f026f..373fc10f 100644 --- a/docs/doc/types.html +++ b/docs/doc/types.html @@ -39,4 +39,3 @@

    A function is called with one or two arguments. A data value (number, character, or array) can also be called the same way, but only a function takes any action when passed arguments, as data just returns itself. Both the one-argument and two-argument calls are considered function calls, and it's common for a function to allow both. A function that always errors in one case or the other might be called a one-argument or two-argument function, depending on which case is allowed.

    Modifiers

    A 1-modifier is called with one operand, while a 2-modifier is called with two. In contrast to functions, these are distinct types, and it is impossible to have a value that can be called with either one or two operands. Also in contrast to functions, data values cannot be called as modifiers: they will cause an error if called this way.

    - diff --git a/docs/doc/windows.html b/docs/doc/windows.html index f2310333..1e301c9e 100644 --- a/docs/doc/windows.html +++ b/docs/doc/windows.html @@ -92,4 +92,3 @@ ↗️
        (+˝≠↕(2⥊0)⊸∾) ⟨2,6,0,1,4,3⟩
 ⟨ 2 8 8 7 5 8 ⟩
    - diff --git a/docs/implementation/codfns.html b/docs/implementation/codfns.html index 1cb63eaf..9b9c14f6 100644 --- a/docs/implementation/codfns.html +++ b/docs/implementation/codfns.html @@ -22,4 +22,3 @@

    Aaron advocates the almost complete separation of code from comments (thesis) in addition to his very terse style as a general programming methodology. I think these choices are good for rapid development but not for maintainance and explaining the code to other developers. I will write separate long-form material on implementation, but will start expanding the source code and adding comments, mainly to explain the meaning of variables whose definitions are not instantly obvious.

    Co-dfns does not check for compilation errors. BQN should have complete error checking, and good error messages. Maybe it can even give better error diagnosis than sequential compilers in some cases by examining the input as a whole to find the most likely cause of the mistake. Particularly for web distribution it may still make sense to have a version of the compiler that doesn't check for errors; this should be possible simply by setting a configuration parameter when compiling the compiler.

    - diff --git a/docs/implementation/index.html b/docs/implementation/index.html index 2ab839e4..0aa8342f 100644 --- a/docs/implementation/index.html +++ b/docs/implementation/index.html @@ -16,4 +16,3 @@
  • Infix to RPN
  • Parsing expressions with parentheses
    • - diff --git a/docs/implementation/vm.html b/docs/implementation/vm.html index 4805d6b1..eef49106 100644 --- a/docs/implementation/vm.html +++ b/docs/implementation/vm.html @@ -540,4 +540,3 @@
  • For a larger test, use test/prim.bqn. The result should be an empty list ⟨⟩ indicating no failed tests.
  • If test/prim.bqn passes you can almost certainly compile the compiler.
    • - diff --git a/docs/index.html b/docs/index.html index 0db21926..e958e80c 100644 --- a/docs/index.html +++ b/docs/index.html @@ -56,4 +56,3 @@

    If you're an array programmer, then you're in much better shape. However, you should be aware of two key differences between BQN and existing array languages beyond just the changes of primitives—if these differences don't seem important to you then you don't understand them! BQN's based array model is different from both a flat array model like J and a nested one like APL2, Dyalog, or GNU APL in that it has true non-array values (plain numbers and characters) that are different from depth-0 scalars. BQN also uses syntactic roles rather than dynamic type to determine how values interact, that is, what's an argument or operand and so on. This system, along with lexical closures, means BQN fully supports Lisp-style functional programming.

    - diff --git a/docs/problems.html b/docs/problems.html index 8190a507..f67eb031 100644 --- a/docs/problems.html +++ b/docs/problems.html @@ -163,4 +163,3 @@

    Fixed with ≍: dyadic form from A+ and monadic/dyadic pair from J.

    Scan and Windowed Reduce shouldn't always reduce

    Fixed with Prefix, Suffix, and Infix operators in J. Changed to functions in BQN.

    - diff --git a/docs/running.html b/docs/running.html index 45745a94..00378fb7 100644 --- a/docs/running.html +++ b/docs/running.html @@ -23,4 +23,3 @@

    The left argument for •EX or the shell arguments can contain up to two arguments for the script. The first is a file to run, and the second is BQN code to be run after it.

    BQN2NGN

    BQN2NGN is a prototype implementation in Javascript build to experiment with the langauge, which is now abandoned. It can be used online here. Major differences are that it has no Fold and Insert is spelled ´ even though current BQN uses ˝, that it has a different version of Group (⊔), and that it is missing Choose (◶). There are also some spelling differences, with Deduplicate (⍷) spelled with ∪ and Valences (⊘) spelled with ⍠. It is missing value blocks and function headers.

    - diff --git a/docs/spec/evaluate.html b/docs/spec/evaluate.html index ab2b6bf4..3ba25d9e 100644 --- a/docs/spec/evaluate.html +++ b/docs/spec/evaluate.html @@ -97,4 +97,3 @@

    As with applications, all expressions are evaluated in reverse source order before doing anything else. Then a result is formed without calling the center value. Its value in BQN is given in the rightmost column, using L, C, and R for the results of the expressions in the left, center, and right columns, respectively. For the first two rules (partial application), the given operand is bound to the 2-modifier: the result is a 1-modifier that, when called, calls the center 2-modifier with the bound operand on the same side it appeared on and the new operand on the remaining side. A train is a function that, when called, calls the right-hand function on all arguments, then the left-hand function, and calls the center function with these results as arguments. In a modifier partial application, the result will fail when applied if the center value does not have the 2-modifier type, and in a fork, it will fail if any component has a modifier type (that is, cannot be applied as a function). BQN implementations are not required to check for these types when forming the result of these expressions, but may give an error on formation even if the result will never be applied.

    - diff --git a/docs/spec/grammar.html b/docs/spec/grammar.html index 66734fc4..b5443ce7 100644 --- a/docs/spec/grammar.html +++ b/docs/spec/grammar.html @@ -141,4 +141,3 @@ | ( subject_allow1 | nothing_allow1 )? Derv_allow1 arg_req1

    Quite tedious. The explosion of rules is partly due to the fact that the brace-typing rule falls into a weaker class of grammars than the other rules. Most of BQN is deterministic context-free but brace-typing is not, only context-free. Fortunately brace typing does not introduce the parsing difficulties that can be present in a general context-free grammar, and it can easily be performed in linear time: after scanning but before parsing, move through the source code maintaining a stack of the current top-level set of braces. Whenever a colon or special name is encountered, annotate that set of braces to indicate that it is present. When a closing brace is encountered and the top brace is popped off the stack, the type is needed if there was no colon, and can be found based on which names were present. One way to present this information to the parser is to replace the brace tokens with new tokens that indicate the type.

    - diff --git a/docs/spec/index.html b/docs/spec/index.html index 3d9ae69a..017ab106 100644 --- a/docs/spec/index.html +++ b/docs/spec/index.html @@ -17,4 +17,3 @@
  • Primitives (reference implementations)
  • Inferred properties (type, Undo, and Under)
    • - diff --git a/docs/spec/inferred.html b/docs/spec/inferred.html index f01450ea..cf8520bd 100644 --- a/docs/spec/inferred.html +++ b/docs/spec/inferred.html @@ -336,4 +336,3 @@ - diff --git a/docs/spec/literal.html b/docs/spec/literal.html index c9e9d362..2b6b5559 100644 --- a/docs/spec/literal.html +++ b/docs/spec/literal.html @@ -17,4 +17,3 @@

    The digits or arabic numerals correspond to the numbers from 0 to 9 in the conventional way (also, each corresponds to its code point value minus 48). A sequence of digits gives a natural number by evaluating it in base 10: the number is 0 for an empty sequence, and otherwise the last digit's numerical value plus ten times the number obtained from the remaining digits. The symbol ∞ indicates infinity and π indicates the ratio pi of a circle's circumference to its diameter (or, for modern mathematicians, the smallest positive real number at which the function {⋆0i1×𝕩} attains a real part of 0). The high minus symbol ¯ indicates that the number containing it is to be negated.

    When an exponent is provided (with e or E), the corresponding mantissa is multiplied by ten to that power, giving the value mantissa×10⋆exponent. If a second component is present (using i or I), that component's value is multiplied by the imaginary unit i and added to the first component; otherwise the value is the first component's value without modification. If complex numbers are not supported, then i should not be allowed in numeric literals, even when followed by 0.

    The above specification describes exactly a complex number with extended real components. To obtain a BQN number, each component is rounded to its nearest representative by the rules of the number system used: for IEEE 754, smallest distance, with ties rounding to the option with even mantissa.

    - diff --git a/docs/spec/scope.html b/docs/spec/scope.html index 6e8dd6ac..3893389e 100644 --- a/docs/spec/scope.html +++ b/docs/spec/scope.html @@ -22,4 +22,3 @@

    A variable is an entity that permits two operations: it can be set to a particular value, and its value can be obtained, resulting in the last value it was set to. When either operation is performed it is referred to as accessing the variable.

    When a body in a block is evaluated, a variable is created for each definition (that is, defined identifier instance) the body contains. Whenever another block—the block itself, not its contents—is evaluated during the execution of the block, it is linked to the currently-evaluating block, so that it will use the variables defined in this instance. These links are recursive, so that every instance of a block is linked to exactly one instance of each block that contains it. These links form a tree that is not necessarily related to the call stack of functions and modifiers. Using these links, the variable an identifier refers to is the one corresponding to that variable's definition in the linked instance of the containing scope for the definition.

    The first access to a variable must be made by its definition (this also means it sets the variable). If a different instance of its identifier accesses it first, then an error results. This can happen because every scope contained in a particular scope sees all the definitions it uses, and such a scope could be called before the definition is run. Because of conditional execution, this property must be checked at run time in general; however, in cases where it is possible to statically determine that a program will always violate it, a BQN instance can give an error at compile time rather than run time.

    - diff --git a/docs/spec/token.html b/docs/spec/token.html index 799ae387..b39b524d 100644 --- a/docs/spec/token.html +++ b/docs/spec/token.html @@ -47,4 +47,3 @@

    In the BQN grammar specification, the three primitive classes are grouped into terminals Fl, _ml, and _cl, while the punctuation characters are identified separately as keywords such as "←". The special names are handled specially. The uppercase versions 𝕎𝕏𝔽𝔾𝕊 and lowercase versions 𝕨𝕩𝕗𝕘𝕤 are two spellings of the five underlying inputs and function.

    - diff --git a/docs/spec/types.html b/docs/spec/types.html index 8c9c694a..3e6f3696 100644 --- a/docs/spec/types.html +++ b/docs/spec/types.html @@ -23,4 +23,3 @@

    To begin the data types, a character is a Unicode code point, that is, its value is a non-negative integer within the ranges defined by Unicode (however, it is distinct from this number as a BQN value). Characters are ordered by this numeric value. BQN deals with code points as abstract entities and does not expose encodings such as UTF-8 or UTF-16.

    The precise type of a number may vary across BQN implementations or instances. A real number is a member of some supported subset of the extended real numbers, that is, the real numbers and positive or negative infinity. Some system must be defined for rounding an arbitrary real number to a member of this subset, and the basic arithmetic operations add, subtract, multiply, divide, and natural exponent (base e) are defined by performing these operations on exact real values and rounding the result. The Power function (dyadic ⋆) is also used but need not be exactly rounded. A complex number is a value with two real number components, a real part and an imaginary part. A BQN implementation can either support real numbers only, or complex numbers.

    An array is a rectangular collection of data. It is defined by a shape, which is a list of non-negative integer lengths, and a ravel, which is a list of elements whose length (the array's bound) is the product of all lengths in the shape. Arrays are defined inductively: any value (of a value or function type) can be used as an element of an array, but it is not possible for an array to contain itself as an element, or an array that contains itself, and so on. Types other than array are called atomic types, and their members are called atoms.

    - diff --git a/docs/tutorial/expression.html b/docs/tutorial/expression.html index 7be7064f..5dfa2251 100644 --- a/docs/tutorial/expression.html +++ b/docs/tutorial/expression.html @@ -317,4 +317,3 @@

    Maybe BQN grammar's not all that bad.

    - diff --git a/docs/tutorial/index.html b/docs/tutorial/index.html index ac8b515d..9978d037 100644 --- a/docs/tutorial/index.html +++ b/docs/tutorial/index.html @@ -12,4 +12,3 @@
  • Expressions
  • List manipulation
    • - diff --git a/docs/tutorial/list.html b/docs/tutorial/list.html index 373da09a..3a389d42 100644 --- a/docs/tutorial/list.html +++ b/docs/tutorial/list.html @@ -288,4 +288,3 @@ ERROR

    Additionally, we saw that the arithmetic functions work naturally on lists, automatically applying to every element of a single list argument or pairing up the elements of two list arguments.

    Even this small amount of list functionality is enough to solve some small problems. We haven't even introduced a function notation yet!

    - -- cgit v1.2.3