Joseph Ferano
d6fc15474b
The author: "I think I prefer length over len, because then I'll use len as the variable name". One arm in check.ml, one row in the table beside it, and every (len x) in lib, test, examples, vendor, spike, docs, web, emacs, plan.org and NEXT.md rewritten. Shadowing and builtin/ had already taken most of the sting out: a (defn len ...) was legal and won in its own file, and builtin/len reached past it. What was left is that len was still a builtin — the defn earned a warning, and a wrapper had to say builtin/ at every inner call. Now there is nothing under the short name: len is an ordinary identifier in every position, which is what (let [len (length xs)] ...) wants. length takes over as shadowing's worked example rather than the feature losing one. shadow-builtin.flan, builtin-qualified.flan, pkgs/shadowed and the builtin/ rows in test_flan move to it and go on testing shadowing. A call to a len nothing defines is answered where an unknown function is, after every table and after the shadowing guard, so a program with its own len never reaches it. The sentence is said rather than guessed at — len and length are three edits apart and the did-you-mean's net is one — and the call is written back out through spell_arg, as-slice's spelling lifted out of it and now shared, so what is printed compiles. sand.flan:33 still calls the old name and is the author's to change; until it does, test_acceptance and test_session abort there. Both were run green against a copy with that one line changed. FIX.org says so.
116 lines
4.3 KiB
Plaintext
116 lines
4.3 KiB
Plaintext
;;;; (Vec T) — spec-memory.md, "The four container types" and "Allocators".
|
|
;;;;
|
|
;;;; ptr + len + cap + allocator, owning and move-only, over one type-erased
|
|
;;;; runtime. The element type appears nowhere in that runtime: size_of and
|
|
;;;; align_of are produced at the call site, which without generics is simply
|
|
;;;; the concrete call site. So this file being two element types with one
|
|
;;;; runtime behind them is the whole claim.
|
|
|
|
(defstruct Point [x i32 y i32])
|
|
|
|
;;; Ownership transfers on the call. The caller's binding is dead after this,
|
|
;;; which is what the refusal cases in test_acceptance assert.
|
|
(defn consume [v (Vec i32)] i32
|
|
(let [n (length v)]
|
|
(free v)
|
|
n))
|
|
|
|
;;; A Vec is returned by moving it out, so the callee's binding is the
|
|
;;; caller's. Nothing is released at function exit — there is no scope-end
|
|
;;; anything in this language.
|
|
(defn make [n i32] (Vec i32)
|
|
(let [v (vec-new i32)]
|
|
(dotimes [i n] (push v (* i i)))
|
|
v))
|
|
|
|
(defn sum [xs [i32]] i32
|
|
(let [total 0]
|
|
(dotimes [i (length xs)] (set total (+ total (at xs i))))
|
|
total))
|
|
|
|
(defn main [] i32
|
|
(let [v (vec-new i32)]
|
|
(println (length v)) ; 0
|
|
(push v 10)
|
|
(push v 20)
|
|
(push v 30)
|
|
(println (length v)) ; 3
|
|
(println (at v 0)) ; 10
|
|
(println (at v 2)) ; 30
|
|
;; A Vec element is a place, and the same bounds and epoch check stands
|
|
;; behind the value form and the place form.
|
|
(set (at v 1) 99)
|
|
(println (at v 1)) ; 99
|
|
|
|
;; slice over a Vec is a non-owning view: it copies ptr+len and never the
|
|
;; elements, and it carries no allocator, so nothing can be freed through
|
|
;; one. [at] and [length] over it are the array operations, unchanged, and
|
|
;; the three arities are the ones every other target has -- the tail form
|
|
;; included, which the Vec had no spelling for while it had a name of its
|
|
;; own. The view is of storage v owns: a push here would move it, and
|
|
;; nothing would say so.
|
|
(println (sum (slice v))) ; 139
|
|
(println (length (slice v 1 3))) ; 2
|
|
(println (at (slice v 1 3) 0)) ; 99
|
|
(println (length (slice v 1))) ; 2
|
|
(println (at (slice v 1) 1)) ; 30
|
|
|
|
;; clone is the only copy: assignment moves. The copy is independent, and
|
|
;; freeing it leaves the original alone.
|
|
(let [w (clone v)]
|
|
(set (at w 0) -1)
|
|
(println (at w 0)) ; -1
|
|
(println (at v 0)) ; 10
|
|
(free w))
|
|
|
|
;; reserve does not change the length, only the capacity, so a reserve
|
|
;; that succeeds is invisible except that the pushes after it do not grow.
|
|
(reserve v 64)
|
|
(println (length v)) ; 3
|
|
(push v 40)
|
|
(println (length v)) ; 4
|
|
|
|
;; The structural printer reaches both new types. Neither is followed: a
|
|
;; Vec's elements are printed through (slice v), which says at the call
|
|
;; site that it borrowed, and an allocator's contents are the runtime's and
|
|
;; its address is not stable across runs.
|
|
(println v) ; <vec>
|
|
(println context/allocator) ; <allocator>
|
|
|
|
(free v))
|
|
|
|
;; A second element type over the same runtime, and a struct element, so
|
|
;; that size_of and align_of are doing work rather than both being 4.
|
|
(let [ps (vec-new Point)]
|
|
(push ps (Point {.x 1 .y 2}))
|
|
(push ps (Point {.x 3 .y 4}))
|
|
(println (length ps)) ; 2
|
|
(println (.y (at ps 1))) ; 4
|
|
(free ps))
|
|
|
|
;; A Vec made against an explicit allocator records it, so free and clone
|
|
;; never need it named again. An arena cannot free one block, so this free
|
|
;; keeps the block — releasing it is free-all's job, and that is the
|
|
;; difference the capability set exists to state.
|
|
(let [a (arena-new 4096)]
|
|
(let [v (vec-new i32 a)]
|
|
(push v 7)
|
|
(println (at v 0)) ; 7
|
|
(free v))
|
|
(println (can-free? a)) ; false
|
|
(free-all a)
|
|
(arena-destroy a))
|
|
|
|
;; The pushes go into whatever the context names, with nothing passed.
|
|
(let [a (arena-new 4096)]
|
|
(with-allocator a
|
|
(let [v (vec-new i32)]
|
|
(push v 5)
|
|
(push v 6)
|
|
(println (+ (at v 0) (at v 1))) ; 11
|
|
(free v)))
|
|
(arena-destroy a))
|
|
|
|
(println (consume (make 5))) ; 5
|
|
0)
|