336 karma · joined October 26, 2015
The distinguishing between arities is a consistent feature of all of these languages. I find fluency comes quickly to it.
Edit: as for intuition between the two, this is sometimes not obvious, but I think it's a sensible generalisation from the monadic case to the dyadic. How else would you want to extend a fold to two arguments?
Having such operators and functions is far from an uncommon experience in j.
'f/ x' is 'insert' - i.e. reduce, so that '+/ 1+i.10' yields 55.
'x f/ y' is 'table', inserting 'f' between each pair to form a generalised multiplication table.
The documentation for j is unsurprisingly terse, but it is complete and very helpful.
I think it may be more convenient to write terse code in BQN over k, because there is greater facility to control function calls in a terse way. Things like under and over are quite common patterns that BQN finds easier (and shorter) than k.
I've not spent a great deal of time yet with BQN, so this could be wrong.
To my knowledge other languages like Julia and numpy don't offer the same range of index-based primitives, like grades, or classifications, which are used pervasively in APLs.
APLs better support a pattern of computing some permutation of a set of arrays, and then viewing other arrays through that permutation, than other languages. You can do it, of course, in numpy, but it's not nearly as pleasant.
The seminal text 'Winning with the Bongcloud', is heartily recommended for anyone looking to understand this new opening.
Here is a pdf link: http://i.4pcdn.org/tg/1401479151063.pdf
The idea is to try and provoke games happening, even if the players come to the table wanting a draw (someone can still botch their opening!). Ultimately though, if GMs want a draw, they'll get it.
If you're producing code for a collected language, you can forward on all of the allocations to that language, and if not, you will need to implement one.
Zero-cost abstractions or not, Idris needs a GC from somewhere.
data Vec : Nat -> Type -> Type
f : Vec 3 Int -> Int
f [1, 2, 3, 4] -- error: wanted a Vec 3 Int, found a Vec 4 Int
import Data.Vect
readInts : (n : Nat) -> IO (Vect n Int)
readInts 0 = pure []
readInts (S n) = do
x <- getLine
rest <- readInts n
pure $ (cast x) :: rest
main : IO ()
main = do
length <- getLine
ints <- readInts (fromInteger . cast $ length)
pure ()
You are required to disambiguate the type before anything useful can be done. What has happened is that you have types being passed around by functions and evaluations which reflect dynamic behaviour at runtime - but there is a type statically known at all times for each part of the program.
Types are values, and types can depend on values - so if your protocol tells you you should be getting a string, a string shows up in the type signature.
There is always a necessary distinction between specification and implementation: if there weren't, one of them would have no value. We often suggest that the intent of a piece of code should be specified in comments, and this is in that category. This way, the compiler can read your comment and figure out if it needs updating! Languages without dependent types work this way too - but you have to try very hard indeed to be eloquent in type signatures, and being able to talk about values lets you say a bit more.
Coming onto your second point: if the function is only valid for some set of values of the given type, why is it 'not really called for' to create specialised types for it? If you call it with something else and it runs, it will be a bug. Newtypes or wrappers are common patterns.
I think that most mainstream typed languages have common constructs to offer that 'A or a B' value you want: this is solved via inheritance, `Either`, `Result`, or `std::variant`.
When moving from dynamically/untyped/unityped languages to those with types, you are liberated from having to check the shape of inputs. If you're given something that claims to be a list of strings, it absolutely is a list of strings, and you can proceed without thinking about it's list-ness or string-ness any further.
When moving from a typed language to a dependently typed language, you are liberated from having to check the state of inputs. You don't have to worry that your file handle is closed, or ensure that you update the state of the object correctly to satisfy some protocol (if you don't, you will be picked up on it!). If you are writing a parser, you don't need to check that the parser returned the form that you just called - you know upfront.
There are other niceties: the type of the function is always a very rough exposition of what the function should do. With dependent types, it becomes considerably clearer. Consider these two functions, which could have very similar implementations (in some Idris-like syntax):
f : Int -> Int -> Bool
data T : Int -> Int -> Type where
Tz : T 0 x
Ts : T a b -> T (a + 1) (b + 1)
g : (x : Int) -> (y : Int) -> Maybe (T x y)
The `x : A` supposes a value, `x`, inhabiting a type `A` (like in Rust, or ML, or maybe `A x` in C).
On the right hand side of the turnstile, we have `B(x) : Type`, which is roughly what it looks like: `B` is a type parameterised by `x` (note - it is not parameterised by `A`, but by `x`! It is allowed to know about the value `x`).
The central turnstile is a contextual relation. The left hand side is an ambient known value, and the right hand side is something that be defined in that context. You can read it informally as "given", so this phrase is "given x: A, we can construct a type B(x)".
3 3 3 ⍴ ⍳10
1 2 3
4 5 6
7 8 9
10 1 2
3 4 5
6 7 8
9 10 1
2 3 4
5 6 7
M ← 3 3 3 ⍴ ⍳10
M*M
1.00000E0 4.00000E0 2.70000E1
2.56000E2 3.12500E3 4.66560E4
8.23543E5 1.67772E7 3.87420E8
1.00000E10 1.00000E0 4.00000E0
2.70000E1 2.56000E2 3.12500E3
4.66560E4 8.23543E5 1.67772E7
3.87420E8 1.00000E10 1.00000E0
4.00000E0 2.70000E1 2.56000E2
3.12500E3 4.66560E4 8.23543E5
How many maps did you want?
x: 10?A:"abcdefghijklmnopqrstuvwxyz"
x
"ysyselacwl"
+`x`y`z!(x;<x;<<x)
x y z
--- - -
"y" 6 8
"s" 7 5
"y" 4 9
"s" 5 6
"e" 9 2
"l" 1 3
"a" 3 0
"c" 8 1
"w" 0 7
"l" 2 4