From 4739618a7f14a224274c40e43471a7fd0bba6c9f Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Wed, 19 Aug 2020 22:52:18 -0400 Subject: Separate pages on primitive functions and types from README --- docs/index.html | 350 +------------------------------------------------------- 1 file changed, 4 insertions(+), 346 deletions(-) (limited to 'docs/index.html') diff --git a/docs/index.html b/docs/index.html index 54c04f47..ec450d92 100644 --- a/docs/index.html +++ b/docs/index.html @@ -30,350 +30,8 @@ 144

For longer samples, you can gaze into the abyss that is the self-hosted compiler, or the shallower but wider abyss of the runtime, or take a look at the friendlier markdown processor used to format and highlight documentation files. There are also some translations from "A History of APL in 50 Functions" here.

-

Array model

-

Most of BQN's functionality deals with the manipulation of multidimensional arrays. However, it discards many of the complications of traditional APL array models. Unlike in APL, non-array data is possible, and common: numbers, characters, and functions are not arrays (see the full list of types below). This avoids some difficulties that show up when trying to treat scalar arrays as the fundamental unit; in particular, there is no "floating" so a value is always different from a scalar array that contains it. This system has been proposed in APL's past under the name based array theory.

-

Currently, the intention is that arrays will not have prototypes, so that all empty arrays of the same shape behave identically. Different elements of an array should not influence each other. While some APLs force numbers placed in the same array to a common representation, which may have different precision properties, BQN will enforce 64-bit floating-point precision, and only use representations or methods compatible with it (for example, integers up to 32 bits).

-

Built-in operations

-

Functions

-

Functions that have significant differences from APL functions are marked with an asterisk. Links for these entries go to dedicated BQN documentation while other links go to the APL Wiki.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GlyphMonadicDyadic
+ConjugateAdd
-NegateSubtract
×SignMultiply
÷ReciprocalDivide
⋆ExponentialPower
√Square RootRoot
⌊FloorMinimum
⌈CeilingMaximum
∧Sort UpAnd*
∨Sort DownOr*
¬Not*Span*
|Absolute ValueModulus
≤Less Than or Equal to
<EncloseLess Than
>Merge*Greater Than
≥Greater Than or Equal to
=RankEquals
≠LengthNot Equals
≡Depth*Match
≢ShapeNot Match
⊣IdentityLeft
⊢IdentityRight
⥊DeshapeReshape
∾Join*Join to
≍Solo*Couple*
↑Prefixes*Take
↓Suffixes*Drop
↕RangeWindows*
⌽ReverseRotate
⍉Transpose*Reorder axes*
/IndicesReplicate
⍋Grade UpBins Up
⍒Grade DownBins Down
⊏First Cell*Select*
⊑FirstPick*
⊐Index of
⊒Occurrence Count*Progressive Index of*
∊Unique MaskMember of
⍷DeduplicateFind
⊔Group Indices*Group*
-

Modifiers

-

Combinators only control the application of functions. Because a non-function operand applies as a constant function, some combinators have extra meanings when passed a constant. For example, 0˜ is the constant function that always returns 0 and 0⊸< is the function that tests whether its right argument is greater than 0.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GlyphName(s)DefinitionDescription
˜Self/Swap{𝕩𝔽𝕨⊣𝕩}Duplicate one argument or exchange two
∘Atop{𝔽𝕨𝔾𝕩}Apply 𝔾 to both arguments and 𝔽 to the result
○Over{(𝔾𝕨)𝔽𝔾𝕩}Apply 𝔾 to each argument and 𝔽 to the results
⊸Before/Bind{(𝔽𝕨⊣𝕩)𝔾𝕩}𝔾's left argument comes from 𝔽
⟜After/Bind{(𝕨⊣𝕩)𝔽𝔾𝕩}𝔽's right argument comes from 𝔾
⌾Under{𝔾⁼∘𝔽○𝔾} OR {(𝔾𝕩)↩𝕨𝔽○𝔾𝕩⋄𝕩}Apply 𝔽 over 𝔾, then undo 𝔾
⊘Valences{𝔽𝕩;𝕨𝔾𝕩}Apply 𝔽 if there's one argument but 𝔾 if there are two
◶Choose{f←(𝕨𝔽𝕩)⊑𝕘 ⋄ 𝕨F𝕩}Select one of the functions in list 𝕘 based on 𝔽
-

Choose isn't really a combinator since it calls the function ⊑, and Under is not a true combinator since it has an "undo" step at the end. This step might be implemented using the left operand's inverse (computational Under) or its structural properties (structural Under).

-

Other modifiers control array traversal and iteration. In three cases a simpler 1-modifier is paired with a generalized 2-modifier: in each case the 1-modifier happens to be the same as the 2-modifier with a right operand of ¯1.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1-ModifierName2-ModifierName
˘Cells⎉Rank
¨Each⚇Depth
⌜Table
⁼Undo⍟Repeat
´Fold
˝Insert
`Scan
-

Types

-

BQN will initially support the following fundamental types:

- -

All of these types are immutable, and immutable types should be the default for BQN. The only mutable type likely to be added is the namespace or scope.

+

How do I get started?

+

Read the documentation!

+

BQN documentation is currently written primarily for array programmers and is not comprehensive, with aspects of the language that are shared with APL poorly documented. If you're not an array programmer, it would probably be better to start with another language, or wait a few weeks. But if you're a serious language enthusiast, the specification is fairly complete and might be enough to fill the gaps in the documentation.

+

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.

-- cgit v1.2.3