mirror of
https://github.com/roc-lang/roc.git
synced 2024-09-11 18:58:24 +03:00
Remove accidental trailing spaces
This commit is contained in:
parent
3eb266c860
commit
1e9d2d1239
4
.github/workflows/benchmarks.yml
vendored
4
.github/workflows/benchmarks.yml
vendored
@ -17,13 +17,13 @@ jobs:
|
||||
- uses: actions/checkout@v2
|
||||
with:
|
||||
ref: "trunk"
|
||||
clean: "true"
|
||||
clean: "true"
|
||||
|
||||
- name: Earthly version
|
||||
run: earthly --version
|
||||
|
||||
- name: on trunk; prepare a self-contained benchmark folder
|
||||
run: ./ci/safe-earthly.sh --build-arg BENCH_SUFFIX=trunk +prep-bench-folder
|
||||
run: ./ci/safe-earthly.sh --build-arg BENCH_SUFFIX=trunk +prep-bench-folder
|
||||
|
||||
- uses: actions/checkout@v2
|
||||
with:
|
||||
|
2
.gitignore
vendored
2
.gitignore
vendored
@ -7,7 +7,7 @@ zig-cache
|
||||
*.o
|
||||
*.tmp
|
||||
|
||||
# llvm human-readable output
|
||||
# llvm human-readable output
|
||||
*.ll
|
||||
*.bc
|
||||
|
||||
|
@ -15,7 +15,7 @@ To run the test suite (via `cargo test`), you additionally need to install:
|
||||
* [`valgrind`](https://www.valgrind.org/) (needs special treatment to [install on macOS](https://stackoverflow.com/a/61359781)
|
||||
Alternatively, you can use `cargo test --no-fail-fast` or `cargo test -p specific_tests` to skip over the valgrind failures & tests.
|
||||
|
||||
For debugging LLVM IR, we use [DebugIR](https://github.com/vaivaswatha/debugir). This dependency is only required to build with the `--debug` flag, and for normal developtment you should be fine without it.
|
||||
For debugging LLVM IR, we use [DebugIR](https://github.com/vaivaswatha/debugir). This dependency is only required to build with the `--debug` flag, and for normal developtment you should be fine without it.
|
||||
|
||||
### libcxb libraries
|
||||
|
||||
|
@ -2325,7 +2325,7 @@ pub mod test_constrain {
|
||||
indoc!(
|
||||
r#"
|
||||
person = { name: "roc" }
|
||||
|
||||
|
||||
person
|
||||
"#
|
||||
),
|
||||
@ -2339,8 +2339,8 @@ pub mod test_constrain {
|
||||
indoc!(
|
||||
r#"
|
||||
person = { name: "roc" }
|
||||
|
||||
{ person & name: "bird" }
|
||||
|
||||
{ person & name: "bird" }
|
||||
"#
|
||||
),
|
||||
"{ name : Str }",
|
||||
@ -2462,7 +2462,7 @@ pub mod test_constrain {
|
||||
indoc!(
|
||||
r#"
|
||||
x = 1
|
||||
|
||||
|
||||
\{} -> x
|
||||
"#
|
||||
),
|
||||
|
@ -511,7 +511,7 @@ fn canonicalize_pending_def<'a>(
|
||||
// remove its generated name from the closure map.
|
||||
let references =
|
||||
env.closures.remove(&closure_symbol).unwrap_or_else(|| {
|
||||
panic!( r"Tried to remove symbol {:?} from procedures, but it was not found: {:?}", closure_symbol, env.closures)
|
||||
panic!( r"Tried to remove symbol {:?} from procedures, but it was not found: {:?}", closure_symbol, env.closures)
|
||||
});
|
||||
|
||||
// TODO should we re-insert this function into env.closures?
|
||||
@ -680,7 +680,7 @@ fn canonicalize_pending_def<'a>(
|
||||
// remove its generated name from the closure map.
|
||||
let references =
|
||||
env.closures.remove(&closure_symbol).unwrap_or_else(|| {
|
||||
panic!( r"Tried to remove symbol {:?} from procedures, but it was not found: {:?}", closure_symbol, env.closures)
|
||||
panic!( r"Tried to remove symbol {:?} from procedures, but it was not found: {:?}", closure_symbol, env.closures)
|
||||
});
|
||||
|
||||
// TODO should we re-insert this function into env.closures?
|
||||
|
@ -116,13 +116,13 @@ mod test_file {
|
||||
indoc!(
|
||||
r#"
|
||||
interface Simple
|
||||
exposes [
|
||||
exposes [
|
||||
v, x
|
||||
]
|
||||
imports []
|
||||
|
||||
|
||||
v : Str
|
||||
|
||||
|
||||
v = "Value!"
|
||||
|
||||
x : Int
|
||||
|
@ -65,7 +65,7 @@ fn finish(all_regressed_benches: HashSet<String>, nr_repeat_benchmarks: usize) {
|
||||
r#"
|
||||
|
||||
FAILED: The following benchmarks have shown a regression {:?} times: {:?}
|
||||
|
||||
|
||||
"#,
|
||||
nr_repeat_benchmarks, all_regressed_benches
|
||||
);
|
||||
|
@ -774,19 +774,19 @@ mod cli_run {
|
||||
indoc!(
|
||||
r#"
|
||||
── UNRECOGNIZED NAME ───────────────────────────────────────────────────────────
|
||||
|
||||
|
||||
I cannot find a `d` value
|
||||
|
||||
|
||||
10│ _ <- await (line d)
|
||||
^
|
||||
|
||||
|
||||
Did you mean one of these?
|
||||
|
||||
|
||||
U8
|
||||
Ok
|
||||
I8
|
||||
F64
|
||||
|
||||
|
||||
────────────────────────────────────────────────────────────────────────────────"#
|
||||
),
|
||||
);
|
||||
|
@ -872,15 +872,15 @@ mod repl_eval {
|
||||
indoc!(
|
||||
r#"
|
||||
── ARGUMENTS BEFORE EQUALS ─────────────────────────────────────────────────────
|
||||
|
||||
|
||||
I am partway through parsing a definition, but I got stuck here:
|
||||
|
||||
|
||||
1│ app "app" provides [ replOutput ] to "./platform"
|
||||
2│
|
||||
3│ replOutput =
|
||||
4│ add m n = m + n
|
||||
^^^
|
||||
|
||||
|
||||
Looks like you are trying to define a function. In roc, functions are
|
||||
always written as a lambda, like increment = \n -> n + 1.
|
||||
"#
|
||||
@ -901,20 +901,20 @@ mod repl_eval {
|
||||
indoc!(
|
||||
r#"
|
||||
── UNSAFE PATTERN ──────────────────────────────────────────────────────────────
|
||||
|
||||
|
||||
This when does not cover all the possibilities:
|
||||
|
||||
|
||||
7│> when t is
|
||||
8│> A -> "a"
|
||||
|
||||
|
||||
Other possibilities include:
|
||||
|
||||
|
||||
B
|
||||
C
|
||||
|
||||
|
||||
I would have to crash if I saw one of those! Add branches for them!
|
||||
|
||||
|
||||
|
||||
|
||||
Enter an expression, or :help, or :exit/:q."#
|
||||
),
|
||||
);
|
||||
|
@ -147,7 +147,7 @@ The compiler contains a lot of code! If you're new to the project it can be hard
|
||||
|
||||
After you get into the details, you'll discover that some parts of the compiler have more than one entry point. And things can be interwoven together in subtle and complex ways, for reasons to do with performance, edge case handling, etc. But if this is "day one" for you, and you're just trying to get familiar with things, this should be "good enough".
|
||||
|
||||
The compiler is invoked from the CLI via `build_file` in cli/src/build.rs
|
||||
The compiler is invoked from the CLI via `build_file` in cli/src/build.rs
|
||||
|
||||
| Phase | Entry point / main functions |
|
||||
| ------------------------------------- | ------------------------------------------------ |
|
||||
|
@ -4,7 +4,7 @@ Builtins are the functions and modules that are implicitly imported into every m
|
||||
|
||||
### module/src/symbol.rs
|
||||
|
||||
Towards the bottom of `symbol.rs` there is a `define_builtins!` macro being used that takes many modules and function names. The first level (`List`, `Int` ..) is the module name, and the second level is the function or value name (`reverse`, `mod` ..). If you wanted to add a `Int` function called `addTwo` go to `2 Int: "Int" => {` and inside that case add to the bottom `38 INT_ADD_TWO: "addTwo"` (assuming there are 37 existing ones).
|
||||
Towards the bottom of `symbol.rs` there is a `define_builtins!` macro being used that takes many modules and function names. The first level (`List`, `Int` ..) is the module name, and the second level is the function or value name (`reverse`, `mod` ..). If you wanted to add a `Int` function called `addTwo` go to `2 Int: "Int" => {` and inside that case add to the bottom `38 INT_ADD_TWO: "addTwo"` (assuming there are 37 existing ones).
|
||||
|
||||
Some of these have `#` inside their name (`first#list`, `#lt` ..). This is a trick we are doing to hide implementation details from Roc programmers. To a Roc programmer, a name with `#` in it is invalid, because `#` means everything after it is parsed to a comment. We are constructing these functions manually, so we are circumventing the parsing step and dont have such restrictions. We get to make functions and values with `#` which as a consequence are not accessible to Roc programmers. Roc programmers simply cannot reference them.
|
||||
|
||||
|
@ -27,7 +27,7 @@ There will be two directories like `roc_builtins-[some random characters]`, look
|
||||
`out` directory as a child.
|
||||
|
||||
> The bitcode is a bunch of bytes that aren't particularly human-readable.
|
||||
> If you want to take a look at the human-readable LLVM IR, look at
|
||||
> If you want to take a look at the human-readable LLVM IR, look at
|
||||
> `target/debug/build/roc_builtins-[some random characters]/out/builtins.ll`
|
||||
|
||||
## Calling bitcode functions
|
||||
|
@ -524,7 +524,7 @@ mod test_can {
|
||||
fn annotation_followed_with_unrelated_affectation() {
|
||||
let src = indoc!(
|
||||
r#"
|
||||
F : Str
|
||||
F : Str
|
||||
|
||||
x = 1
|
||||
|
||||
@ -545,10 +545,10 @@ mod test_can {
|
||||
fn two_annotations_followed_with_unrelated_affectation() {
|
||||
let src = indoc!(
|
||||
r#"
|
||||
G : Str
|
||||
G : Str
|
||||
|
||||
F : {}
|
||||
|
||||
F : {}
|
||||
|
||||
x = 1
|
||||
|
||||
x
|
||||
@ -629,7 +629,7 @@ mod test_can {
|
||||
fn incorrect_optional_value() {
|
||||
let src = indoc!(
|
||||
r#"
|
||||
{ x ? 42 }
|
||||
{ x ? 42 }
|
||||
"#
|
||||
);
|
||||
let arena = Bump::new();
|
||||
@ -1004,7 +1004,7 @@ mod test_can {
|
||||
let src = indoc!(
|
||||
r#"
|
||||
x = Dict.empty
|
||||
|
||||
|
||||
Dict.len x
|
||||
"#
|
||||
);
|
||||
|
@ -410,19 +410,19 @@ mod test_fmt {
|
||||
indoc!(
|
||||
r#"
|
||||
x = (5)
|
||||
|
||||
|
||||
|
||||
|
||||
y = ((10))
|
||||
|
||||
|
||||
42
|
||||
"#
|
||||
),
|
||||
indoc!(
|
||||
r#"
|
||||
x = 5
|
||||
|
||||
|
||||
y = 10
|
||||
|
||||
|
||||
42
|
||||
"#
|
||||
),
|
||||
@ -766,9 +766,9 @@ mod test_fmt {
|
||||
|
||||
# comment 2
|
||||
x: 42
|
||||
|
||||
|
||||
# comment 3
|
||||
|
||||
|
||||
# comment 4
|
||||
}"#
|
||||
),
|
||||
@ -819,7 +819,7 @@ mod test_fmt {
|
||||
f: { y : Int *,
|
||||
x : Int * ,
|
||||
}
|
||||
|
||||
|
||||
f"#
|
||||
),
|
||||
indoc!(
|
||||
@ -910,7 +910,7 @@ mod test_fmt {
|
||||
{
|
||||
# comment
|
||||
}
|
||||
|
||||
|
||||
f"#
|
||||
),
|
||||
);
|
||||
@ -935,7 +935,7 @@ mod test_fmt {
|
||||
indoc!(
|
||||
r#"
|
||||
f :
|
||||
{
|
||||
{
|
||||
x: Int * # comment 1
|
||||
,
|
||||
# comment 2
|
||||
@ -951,7 +951,7 @@ mod test_fmt {
|
||||
# comment 1
|
||||
# comment 2
|
||||
}
|
||||
|
||||
|
||||
f"#
|
||||
),
|
||||
);
|
||||
@ -1007,7 +1007,7 @@ mod test_fmt {
|
||||
indoc!(
|
||||
r#"
|
||||
identity = \a
|
||||
->
|
||||
->
|
||||
a + b
|
||||
|
||||
identity 4010
|
||||
@ -1387,7 +1387,7 @@ mod test_fmt {
|
||||
expr_formats_to(
|
||||
indoc!(
|
||||
r#"
|
||||
{
|
||||
{
|
||||
}"#
|
||||
),
|
||||
"{}",
|
||||
@ -2763,7 +2763,7 @@ mod test_fmt {
|
||||
# comment 2
|
||||
# comment 3
|
||||
]
|
||||
|
||||
|
||||
b
|
||||
"#
|
||||
),
|
||||
|
@ -3,7 +3,7 @@ interface ManualAttr
|
||||
imports []
|
||||
|
||||
# manually replicates the Attr wrapping that uniqueness inference uses, to try and find out why they are different
|
||||
# It is very important that there are no signatures here! elm uses an optimization that leads to less copying when
|
||||
# It is very important that there are no signatures here! elm uses an optimization that leads to less copying when
|
||||
# signatures are given.
|
||||
|
||||
map =
|
||||
|
@ -3,7 +3,7 @@ interface ManualAttr
|
||||
imports []
|
||||
|
||||
# manually replicates the Attr wrapping that uniqueness inference uses, to try and find out why they are different
|
||||
# It is very important that there are no signatures here! elm uses an optimization that leads to less copying when
|
||||
# It is very important that there are no signatures here! elm uses an optimization that leads to less copying when
|
||||
# signatures are given.
|
||||
|
||||
map =
|
||||
|
@ -276,9 +276,9 @@ mod test_load {
|
||||
"Main",
|
||||
indoc!(
|
||||
r#"
|
||||
app "test-app"
|
||||
packages { blah: "./blah" }
|
||||
imports [ RBTree ]
|
||||
app "test-app"
|
||||
packages { blah: "./blah" }
|
||||
imports [ RBTree ]
|
||||
provides [ main ] to blah
|
||||
|
||||
empty : RBTree.RedBlackTree I64 I64
|
||||
@ -541,7 +541,7 @@ mod test_load {
|
||||
indoc!(
|
||||
"
|
||||
\u{1b}[36m── UNFINISHED LIST ─────────────────────────────────────────────────────────────\u{1b}[0m
|
||||
|
||||
|
||||
I cannot find the end of this list:
|
||||
|
||||
\u{1b}[36m3\u{1b}[0m\u{1b}[36m│\u{1b}[0m \u{1b}[37mmain = [\u{1b}[0m
|
||||
|
@ -498,7 +498,7 @@ fn specialize_row_by_ctor2(
|
||||
patterns.extend(args);
|
||||
matrix.push(patterns);
|
||||
} else {
|
||||
// do nothing
|
||||
// do nothing
|
||||
}
|
||||
Some(Anything) => {
|
||||
// TODO order!
|
||||
|
@ -61,7 +61,7 @@ pub struct ExprParseOptions {
|
||||
|
||||
/// Check for the `->` token, and raise an error if found
|
||||
/// This is usually true, but false in if-guards
|
||||
///
|
||||
///
|
||||
/// > Just foo if foo == 2 -> ...
|
||||
check_for_arrow: bool,
|
||||
}
|
||||
|
@ -59,7 +59,7 @@ In some cases, the compiler can detect that no reference counting is necessary.
|
||||
|
||||
The fact that the reference count may or may not be present could creat a tricky situation for some `List` operations.
|
||||
|
||||
For example, should `List.get 0` return the first 16B of the heap-allocated bytes, or the second 16B? If there's a reference count in the first 16B, it should return the second 16B. If there's no refcount, it should return the first 16B.
|
||||
For example, should `List.get 0` return the first 16B of the heap-allocated bytes, or the second 16B? If there's a reference count in the first 16B, it should return the second 16B. If there's no refcount, it should return the first 16B.
|
||||
|
||||
To solve this, the pointer in the List struct *always* points to the first element in the list. That means to access the reference count, it does negative pointer arithmetic to get the address at 16B *preceding* the memory address it has stored in its pointer field.
|
||||
|
||||
|
@ -551,10 +551,10 @@ fn rosetree_with_tag() {
|
||||
r#"
|
||||
Rose a : [ Rose (Result (List (Rose a)) I64) ]
|
||||
|
||||
x : Rose I64
|
||||
x : Rose I64
|
||||
x = (Rose (Ok []))
|
||||
|
||||
y : Rose I64
|
||||
y : Rose I64
|
||||
y = (Rose (Ok []))
|
||||
|
||||
x == y
|
||||
@ -637,10 +637,10 @@ fn compare_recursive_union_same_content() {
|
||||
r#"
|
||||
Expr : [ Add Expr Expr, Mul Expr Expr, Val1 I64, Val2 I64 ]
|
||||
|
||||
v1 : Expr
|
||||
v1 : Expr
|
||||
v1 = Val1 42
|
||||
|
||||
v2 : Expr
|
||||
v2 : Expr
|
||||
v2 = Val2 42
|
||||
|
||||
v1 == v2
|
||||
@ -659,10 +659,10 @@ fn compare_nullable_recursive_union_same_content() {
|
||||
r#"
|
||||
Expr : [ Add Expr Expr, Mul Expr Expr, Val1 I64, Val2 I64, Empty ]
|
||||
|
||||
v1 : Expr
|
||||
v1 : Expr
|
||||
v1 = Val1 42
|
||||
|
||||
v2 : Expr
|
||||
v2 : Expr
|
||||
v2 = Val2 42
|
||||
|
||||
v1 == v2
|
||||
|
@ -997,7 +997,7 @@ fn both_have_unique_fields() {
|
||||
b = { x: 42, z: 44 }
|
||||
|
||||
f : { x : I64 }a, { x : I64 }b -> I64
|
||||
f = \{ x: x1}, { x: x2 } -> x1 + x2
|
||||
f = \{ x: x1}, { x: x2 } -> x1 + x2
|
||||
|
||||
f a b
|
||||
"#
|
||||
|
@ -34,7 +34,7 @@ fn with_default() {
|
||||
indoc!(
|
||||
r#"
|
||||
result : Result I64 {}
|
||||
result = Err {}
|
||||
result = Err {}
|
||||
|
||||
Result.withDefault result 0
|
||||
"#
|
||||
@ -66,7 +66,7 @@ fn result_map() {
|
||||
indoc!(
|
||||
r#"
|
||||
result : Result I64 {}
|
||||
result = Err {}
|
||||
result = Err {}
|
||||
|
||||
result
|
||||
|> Result.map (\x -> x + 1)
|
||||
@ -230,7 +230,7 @@ fn roc_result_ok() {
|
||||
indoc!(
|
||||
r#"
|
||||
result : Result I64 {}
|
||||
result = Ok 42
|
||||
result = Ok 42
|
||||
|
||||
result
|
||||
"#
|
||||
@ -246,7 +246,7 @@ fn roc_result_err() {
|
||||
assert_evals_to!(
|
||||
indoc!(
|
||||
r#"
|
||||
result : Result I64 Str
|
||||
result : Result I64 Str
|
||||
result = Err "foo"
|
||||
|
||||
result
|
||||
|
@ -121,7 +121,7 @@ fn union() {
|
||||
set1 = Set.fromList [1,2]
|
||||
|
||||
set2 : Set I64
|
||||
set2 = Set.fromList [1,3,4]
|
||||
set2 = Set.fromList [1,3,4]
|
||||
|
||||
Set.union set1 set2
|
||||
|> Set.toList
|
||||
@ -142,7 +142,7 @@ fn difference() {
|
||||
set1 = Set.fromList [1,2]
|
||||
|
||||
set2 : Set I64
|
||||
set2 = Set.fromList [1,3,4]
|
||||
set2 = Set.fromList [1,3,4]
|
||||
|
||||
Set.difference set1 set2
|
||||
|> Set.toList
|
||||
@ -163,7 +163,7 @@ fn intersection() {
|
||||
set1 = Set.fromList [1,2]
|
||||
|
||||
set2 : Set I64
|
||||
set2 = Set.fromList [1,3,4]
|
||||
set2 = Set.fromList [1,3,4]
|
||||
|
||||
Set.intersection set1 set2
|
||||
|> Set.toList
|
||||
|
@ -7,12 +7,12 @@ procedure Test.0 ():
|
||||
case 2:
|
||||
let Test.2 : Builtin(Int(I64)) = UnionAtIndex (Id 2) (Index 0) Test.5;
|
||||
ret Test.2;
|
||||
|
||||
|
||||
case 0:
|
||||
let Test.3 : Builtin(Int(I64)) = UnionAtIndex (Id 0) (Index 0) Test.5;
|
||||
ret Test.3;
|
||||
|
||||
|
||||
default:
|
||||
let Test.4 : Builtin(Int(I64)) = UnionAtIndex (Id 1) (Index 0) Test.5;
|
||||
ret Test.4;
|
||||
|
||||
|
||||
|
@ -32,11 +32,11 @@ procedure Test.5 (Test.8, Test.9):
|
||||
case 0:
|
||||
let Test.16 : Builtin(Int(I64)) = CallByName Test.3 Test.9;
|
||||
jump Test.15 Test.16;
|
||||
|
||||
|
||||
default:
|
||||
let Test.17 : Builtin(Int(I64)) = CallByName Test.4 Test.9;
|
||||
jump Test.15 Test.17;
|
||||
|
||||
|
||||
|
||||
procedure Test.0 ():
|
||||
joinpoint Test.19 Test.12:
|
||||
|
@ -15,11 +15,11 @@ procedure Test.1 (Test.2, Test.3):
|
||||
case 0:
|
||||
let Test.19 : Builtin(Int(I64)) = CallByName Test.7 Test.3 Test.2;
|
||||
jump Test.18 Test.19;
|
||||
|
||||
|
||||
default:
|
||||
let Test.20 : Builtin(Int(I64)) = CallByName Test.8 Test.3 Test.2;
|
||||
jump Test.18 Test.20;
|
||||
|
||||
|
||||
|
||||
procedure Test.7 (Test.10, #Attr.12):
|
||||
let Test.4 : Builtin(Int(I64)) = UnionAtIndex (Id 0) (Index 0) #Attr.12;
|
||||
|
@ -29,11 +29,11 @@ procedure Test.0 ():
|
||||
case 0:
|
||||
let Test.16 : Builtin(Int(I64)) = CallByName Test.6 Test.12 Test.13;
|
||||
jump Test.15 Test.16;
|
||||
|
||||
|
||||
default:
|
||||
let Test.17 : Builtin(Int(I64)) = CallByName Test.7 Test.12 Test.13;
|
||||
jump Test.15 Test.17;
|
||||
|
||||
|
||||
in
|
||||
let Test.22 : Builtin(Bool) = true;
|
||||
if Test.22 then
|
||||
|
@ -7,15 +7,15 @@ procedure Test.1 (Test.5):
|
||||
case 1:
|
||||
let Test.10 : Builtin(Int(I64)) = 1i64;
|
||||
jump Test.9 Test.10;
|
||||
|
||||
|
||||
case 2:
|
||||
let Test.11 : Builtin(Int(I64)) = 2i64;
|
||||
jump Test.9 Test.11;
|
||||
|
||||
|
||||
default:
|
||||
let Test.12 : Builtin(Int(I64)) = 3i64;
|
||||
jump Test.9 Test.12;
|
||||
|
||||
|
||||
|
||||
procedure Test.0 ():
|
||||
let Test.7 : Struct([]) = Struct {};
|
||||
|
@ -982,17 +982,17 @@ fn closure_in_list() {
|
||||
indoc!(
|
||||
r#"
|
||||
app "test" provides [ main ] to "./platform"
|
||||
|
||||
|
||||
foo = \{} ->
|
||||
x = 41
|
||||
|
||||
|
||||
f = \{} -> x
|
||||
|
||||
|
||||
[ f ]
|
||||
|
||||
|
||||
main =
|
||||
items = foo {}
|
||||
|
||||
|
||||
List.len items
|
||||
"#
|
||||
)
|
||||
@ -1005,7 +1005,7 @@ fn somehow_drops_definitions() {
|
||||
r#"
|
||||
app "test" provides [ main ] to "./platform"
|
||||
|
||||
one : I64
|
||||
one : I64
|
||||
one = 1
|
||||
|
||||
two : I64
|
||||
@ -1037,7 +1037,7 @@ fn specialize_closures() {
|
||||
apply = \f, x -> f x
|
||||
|
||||
main =
|
||||
one : I64
|
||||
one : I64
|
||||
one = 1
|
||||
|
||||
two : I64
|
||||
|
@ -42,7 +42,7 @@ From roc to render:
|
||||
- The `ed_model` is filled in part with data obtained by loading and typechecking the roc file with the same function (`load_and_typecheck`) that is used by the compiler.
|
||||
- `ed_model` also contains an `EdModule`, which holds the parsed abstract syntax tree (AST).
|
||||
- In the `init_model` function:
|
||||
+ The AST is converted into a tree of `MarkupNode`. The different types of `MarkupNode` are similar to the elements/nodes in HTML. A line of roc code is represented as a nested `MarkupNode` containing mostly text `MarkupNode`s. The line `foo = "bar"` is represented as
|
||||
+ The AST is converted into a tree of `MarkupNode`. The different types of `MarkupNode` are similar to the elements/nodes in HTML. A line of roc code is represented as a nested `MarkupNode` containing mostly text `MarkupNode`s. The line `foo = "bar"` is represented as
|
||||
three text `MarkupNode` representing `foo`, ` = ` and `bar`. Multiple lines of roc code are represented as nested `MarkupNode` that contain other nested `MarkupNode`.
|
||||
+ `CodeLines` holds a `Vec` of `String`, each line of code is a `String`. When saving the file, the content of `CodeLines` is written to disk.
|
||||
+ `GridNodeMap` maps every position of a char of roc code to a `MarkNodeId`, for easy interaction with the caret.
|
||||
|
@ -48,7 +48,7 @@ Nice collection of research on innovative editors, [link](https://futureofcoding
|
||||
* [Hest](https://ivanish.ca/hest-time-travel/) tool for making highly interactive simulations.
|
||||
* [replit](https://replit.com/) collaborative browser based IDE.
|
||||
* [paper](https://openreview.net/pdf?id=SJeqs6EFvB) on finding and fixing bugs automatically.
|
||||
* [specialized editors that can be embedded in main editor](https://elliot.website/editor/)
|
||||
* [specialized editors that can be embedded in main editor](https://elliot.website/editor/)
|
||||
* Say you have a failing test that used to work, it would be very valuable to see all code that was changed that was used only by that test.
|
||||
e.g. you have a test `calculate_sum_test` that only uses the function `add`, when the test fails you should be able to see a diff showing only what changed for the function `add`. It would also be great to have a diff of [expression values](https://homepages.cwi.nl/~storm/livelit/images/bret.png) Bret Victor style. An ambitious project would be to suggest or automatically try fixes based on these diffs.
|
||||
* I think it could be possible to create a minimal reproduction of a program / block of code / code used by a single test. So for a failing unit test I would expect it to extract imports, the platform, types and functions that are necessary to run only that unit test and put them in a standalone roc project. This would be useful for sharing bugs with library+application authors and colleagues, for profiling or debugging with all "clutter" removed.
|
||||
@ -138,7 +138,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
* "complex" filtered search: search for all occurrences of `"#` but ignore all like `"#,`
|
||||
* color this debug print orange
|
||||
* remove unused imports
|
||||
|
||||
|
||||
#### Inspiration
|
||||
|
||||
* Voice control and eye tracking with [Talon](https://github.com/Gauteab/talon-tree-sitter-service)
|
||||
@ -157,13 +157,13 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
|
||||
### Productivity features
|
||||
|
||||
* When refactoring;
|
||||
* When refactoring;
|
||||
- Cutting and pasting code to a new file should automatically add imports to the new file and delete them from the old file.
|
||||
- Ability to link e.g. variable name in comments to actual variable name. Comment is automatically updated when variable name is changed.
|
||||
- When updating dependencies with breaking changes; show similar diffs from github projects that have successfully updated that dependency.
|
||||
- AST backed renaming, changing variable/function/type name should change it all over the codebase.
|
||||
- AST backed renaming, changing variable/function/type name should change it all over the codebase.
|
||||
* Automatically create all "arms" when pattern matching after entering `when var is` based on the type.
|
||||
- All `when ... is` should be updated if the type is changed, e.g. adding Indigo to the Color type should add an arm everywhere where `when color is` is used.
|
||||
- All `when ... is` should be updated if the type is changed, e.g. adding Indigo to the Color type should add an arm everywhere where `when color is` is used.
|
||||
* When a function is called like `foo(false)`, the name of the boolean argument should be shown automatically; `foo(`*is_active:*`false)`. This should be done for booleans and numbers.
|
||||
* Suggest automatically creating a function if the compiler says it does not exist.
|
||||
* Integrated search:
|
||||
@ -171,7 +171,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
* Show productivity/feature tips on startup. Show link to page with all tips. Allow not seeing tips next time.
|
||||
* Search friendly editor docs inside the editor. Offer to send search string to Roc maintainers when no results, or if no results were clicked.
|
||||
* File history timeline view. Show timeline with commits that changed this file, the number of lines added and deleted as well as which user made the changes. Arrow navigation should allow you to quickly view different versions of the file.
|
||||
* Suggested quick fixes should be directly visible and clickable. Not like in vs code where you put the caret on an error until a lightbulb appears in the margin which you have to click for the fixes to appear, after which you click to apply the fix you want :( . You should be able to apply suggestions in rapid succession. e.g. if you copy some roc code from the internet you should be able to apply 5 import suggestions quickly.
|
||||
* Suggested quick fixes should be directly visible and clickable. Not like in vs code where you put the caret on an error until a lightbulb appears in the margin which you have to click for the fixes to appear, after which you click to apply the fix you want :( . You should be able to apply suggestions in rapid succession. e.g. if you copy some roc code from the internet you should be able to apply 5 import suggestions quickly.
|
||||
* Regex-like find and substitution based on plain english description and example (replacement). i.e. replace all `[` between double quotes with `{`. [Inspiration](https://alexmoltzau.medium.com/english-to-regex-thanks-to-gpt-3-13f03b68236e).
|
||||
* Show productivity tips based on behavior. i.e. if the user is scrolling through the error bar and clicking on the next error several times, show a tip with "go to next error" shortcut.
|
||||
* Command to "benchmark this function" or "benchmark this test" with flamegraph and execution time per line.
|
||||
@ -201,7 +201,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
* Intelligent search: "search this folder for <term>", "search all tests for <term>"
|
||||
* Show some kind of warning if path str in code does not exist locally.
|
||||
* repl on panic/error: ability to inspect all values and try executing some things at the location of the error.
|
||||
* show values in memory on panic/error
|
||||
* show values in memory on panic/error
|
||||
* automatic clustering of (text) search results in groups by similarity
|
||||
* fill screen with little windows of clustered search results
|
||||
* clustering of examples similar to current code
|
||||
@ -222,7 +222,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
* GPT-3 can generate correct python functions based on a comment describing the functionality, video [here](https://www.youtube.com/watch?v=utuz7wBGjKM). It's possible that training a model using ast's may lead to better results than text based models.
|
||||
- Current autocomplete lacks flow, moving through suggestions with arrows is slow. Being able to code by weaving together autocomplete suggestions laid out in rows using eye tracking, that could flow.
|
||||
- It's possible that with strong static types, pure functions and a good search algorithm we can develop a more reliable autocomplete than one with machine learning.
|
||||
- When ranking autocomplete suggestions, take into account how new a function is. Newly created functions are likely to be used soon.
|
||||
- When ranking autocomplete suggestions, take into account how new a function is. Newly created functions are likely to be used soon.
|
||||
|
||||
#### Productivity Inspiration
|
||||
|
||||
@ -239,7 +239,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
* [Codesee](https://www.codesee.io/) code base visualization.
|
||||
* [Loopy](https://dl.acm.org/doi/10.1145/3485530?sid=SCITRUS) interactive program synthesis.
|
||||
* [bracket guides](https://mobile.twitter.com/elyktrix/status/1461380028609048576)
|
||||
|
||||
|
||||
### Non-Code Related Inspiration
|
||||
|
||||
* [Scrivner](https://www.literatureandlatte.com/scrivener/overview) writing app for novelists, screenwriters, and more
|
||||
@ -266,7 +266,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
|
||||
|
||||
## Testing
|
||||
|
||||
|
||||
* From Google Docs' comments, adding tests in a similar manner, where they exists in the same "document" but parallel to the code being written
|
||||
* Makes sense for unit tests, keeps the test close to the source
|
||||
* Doesn't necessarily make sense for integration or e2e testing
|
||||
@ -295,7 +295,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
* Library should have cheat sheet with most used/important docs summarized.
|
||||
* With explicit user permission, anonymously track viewing statistics for documentation. Can be used to show most important documentation, report pain points to library authors.
|
||||
* Easy side-by-side docs for multiple versions of library.
|
||||
* ability to add questions and answers to library documentation
|
||||
* ability to add questions and answers to library documentation
|
||||
|
||||
## Tutorials
|
||||
|
||||
@ -350,28 +350,28 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
|
||||
Thoughts and ideas possibly taken from above inspirations or separate.
|
||||
|
||||
* ACCESSIBILITY === EMPATHY
|
||||
* Visual Imapirments
|
||||
* Visual Imapirments
|
||||
No Animation is most benign form of cognitive disabity but really important base line of people with tense nerve system.
|
||||
Insensitivity to certain or all colors.
|
||||
Need of highcontrast
|
||||
Or Everything Magnified for me with no glasses.
|
||||
Or Everything Magnified for me with no glasses.
|
||||
Or Total blindness where we need to trough sound to communicate to the user
|
||||
Screen readers read trees of labeled elements. Each platform has different apis, but I think they are horrible. Just close your eyes and imagine listening to screen reader all day while you are using this majectic machines called computers.
|
||||
But blind people walk with a tool and they can react much better to sound/space relations than full on visal majority does. They are acute to sound as a spatial hint. And a hand for most of them is a very sensitive tool that can make sounds in space.
|
||||
Imagine if everytime for the user doesnt want to rely on shining rendered pixels on the screen for a feedback from machine, we make a acoustic room simulation, where with moving the "stick", either with mouse or with key arrows, we bump into one of the objects and that produces certain contextually appropriate sound (clean)*ding*
|
||||
|
||||
|
||||
On the each level of abstraction they can make sounds more deeper, so then when you type letters you feel like you are playing with the sand (soft)*shh*. We would need help from some sound engineer about it, but imagine moving down, which can be voice triggered command for motion impaired, you hear (soft)*pup* and the name of the module, and then you have options and commands appropriate for the module, they could map to those basic 4 buttons that we trained user on, and he would shortcut all the soft talk with click of a button. Think of the satisfaction when you can skip the dialog of the game and get straight into action. (X) Open functions! each function would make a sound and say its name, unless you press search and start searching for a specific function inside module, if you want one you select or move to next.
|
||||
- Related idea: Playing sounds in rapid succession for different expressions in your program might be a high throughput alternative to stepping through your code line by line. I'd bet you quickly learn what your program should sound like. The difference in throughput would be even larger for those who need to rely on voice transcription.
|
||||
|
||||
|
||||
* Motor impariments
|
||||
[rant]BACKS OF CODERS ARE NOT HEALTHY! We need to change that![/neverstop]
|
||||
Too much mouse waving and sitting for too long is bad for humans.
|
||||
Keyboard is basic accessability tool but
|
||||
Keyboard is also optional, some people have too shaky hands even for keyboard.
|
||||
Keyboard is basic accessability tool but
|
||||
Keyboard is also optional, some people have too shaky hands even for keyboard.
|
||||
They rely on eye tracking to move mouse cursor arond.
|
||||
If we employ _some_ voice recognition functions we could make same interface as we could do for consoles where 4+2 buttons and directional pad would suffice.
|
||||
That is 10 phrases that need to be pulled trough as many possible translations so people don't have to pretend that they are from Maine or Texas so they get voice recognition to work. Believe me I was there with Apple's Siri :D That is why we have 10 phrases for movement and management and most basic syntax.
|
||||
* Builtin fonts that can be read more easily by those with dyslexia.
|
||||
* Builtin fonts that can be read more easily by those with dyslexia.
|
||||
|
||||
* Nice backtraces that highlight important information
|
||||
* Ability to show import connection within project visually
|
||||
|
@ -67,10 +67,10 @@ Snippets are inserted based on type of value on which the cursor is located.
|
||||
|
||||
- command: sort ^List *^ (by ^Record Field^) {ascending/descending}
|
||||
+ example: sort people by age descending >> ...
|
||||
- command: escape url
|
||||
- command: escape url
|
||||
+ example: >> `percEncodedString = Url.percentEncode ^String^`
|
||||
- command: list files in directory
|
||||
+ example: >>
|
||||
+ example: >>
|
||||
```
|
||||
path <- File.pathFromStr ^String^
|
||||
dirContents <- File.enumerateDir path
|
||||
@ -90,9 +90,9 @@ Snippets are inserted based on type of value on which the cursor is located.
|
||||
* repeat list > List.repeat ^elem^ ^Nat^
|
||||
* len list (fuzzy matches should be length of list)
|
||||
- append element to list
|
||||
|
||||
|
||||
# fuzzy matching
|
||||
|
||||
|
||||
some pairs for fuzzy matching unit tests:
|
||||
- hashmap > Dict
|
||||
- map > map (function), Dict
|
||||
@ -108,6 +108,6 @@ Snippets are inserted based on type of value on which the cursor is located.
|
||||
|
||||
- [grepper](https://www.codegrepper.com/) snippet collection that embeds in google search results. See also this [collection of common questions](https://www.codegrepper.com/code-examples/rust).
|
||||
- [github copilot](https://copilot.github.com/) snippet generation with machine learning
|
||||
- [stackoverflow](https://stackoverflow.com)
|
||||
- [stackoverflow](https://stackoverflow.com)
|
||||
- [rosetta code](http://www.rosettacode.org/wiki/Rosetta_Code) snippets in many different programming languages. Many [snippets](https://www.rosettacode.org/wiki/Category:Programming_Tasks) are programming contest style problems, but there also problems that demonstrate the use of JSON, SHA-256, read a file line by line...
|
||||
- check docs of popular languages to cross reference function/snippet names for fuzzy matching
|
||||
|
@ -18,10 +18,10 @@ fn vs_main(
|
||||
[[location(1)]] in_color: vec4<f32>,
|
||||
) -> VertexOutput {
|
||||
var out: VertexOutput;
|
||||
|
||||
|
||||
out.position = u_globals.ortho * vec4<f32>(in_position, 0.0, 1.0);
|
||||
out.color = in_color;
|
||||
|
||||
|
||||
return out;
|
||||
}
|
||||
|
||||
|
@ -21,7 +21,7 @@ impl Modifiers {
|
||||
// returns true if modifiers are active that can be active when the user wants to insert a new char; e.g.: shift+a to make A
|
||||
pub fn new_char_modifiers(&self) -> bool {
|
||||
self.no_modifiers()
|
||||
|| (self.shift && !self.ctrl && !self.alt && !self.logo) // e.g.: shift+a to make A
|
||||
|| (self.shift && !self.ctrl && !self.alt && !self.logo) // e.g.: shift+a to make A
|
||||
|| (self.cmd_or_ctrl() && self.alt) // e.g.: ctrl+alt+2 to make @ on azerty keyboard
|
||||
}
|
||||
|
||||
|
@ -8,7 +8,7 @@ With the interpreter, it currently runs about 350x slower though and requires ex
|
||||
Load 256 constants from https://github.com/wertarbyte/coreutils/blob/f70c7b785b93dd436788d34827b209453157a6f2/src/cksum.c#L117
|
||||
To support the original false interpreter, numbers must be less than 32000.
|
||||
To deal with loading, just split all the numbers in two chunks.
|
||||
First chunk is lower 16 bits, second chunk is higher 16 bits shift to the right.
|
||||
First chunk is lower 16 bits, second chunk is higher 16 bits shift to the right.
|
||||
Its values are then shifted back and merged together.
|
||||
}
|
||||
16564 45559 65536*| 23811 46390 65536*| 31706 47221 65536*| 26221 48308 65536*|
|
||||
@ -199,7 +199,7 @@ i;
|
||||
|
||||
{left shift it by 8 (multiply by 0x100)}
|
||||
256*
|
||||
|
||||
|
||||
{xor with the loaded constant}
|
||||
x;!
|
||||
|
||||
|
@ -25,7 +25,7 @@ extension RocStr {
|
||||
var isSmallString: Bool {
|
||||
len < 0
|
||||
}
|
||||
|
||||
|
||||
var length: Int {
|
||||
if isSmallString {
|
||||
var len = len
|
||||
@ -37,7 +37,7 @@ extension RocStr {
|
||||
return len
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
var string: String {
|
||||
if isSmallString {
|
||||
let data: Data = withUnsafePointer(to: self) { ptr in
|
||||
|
@ -14,17 +14,17 @@ $ cargo run --release Hello.roc
|
||||
|
||||
## Design Notes
|
||||
|
||||
This demonstrates the basic design of hosts: Roc code gets compiled into a pure
|
||||
This demonstrates the basic design of hosts: Roc code gets compiled into a pure
|
||||
function (in this case, a thunk that always returns `"Hello, World!"`) and
|
||||
then the host calls that function. Fundamentally, that's the whole idea! The host
|
||||
might not even have a `main` - it could be a library, a plugin, anything.
|
||||
Everything else is built on this basic "hosts calling linked pure functions" design.
|
||||
|
||||
For example, things get more interesting when the compiled Roc function returns
|
||||
a `Task` - that is, a tagged union data structure containing function pointers
|
||||
to callback closures. This lets the Roc pure function describe arbitrary
|
||||
chainable effects, which the host can interpret to perform I/O as requested by
|
||||
the Roc program. (The tagged union `Task` would have a variant for each supported
|
||||
a `Task` - that is, a tagged union data structure containing function pointers
|
||||
to callback closures. This lets the Roc pure function describe arbitrary
|
||||
chainable effects, which the host can interpret to perform I/O as requested by
|
||||
the Roc program. (The tagged union `Task` would have a variant for each supported
|
||||
I/O operation.)
|
||||
|
||||
In this trivial example, it's very easy to line up the API between the host and
|
||||
@ -39,6 +39,6 @@ Roc application authors only care about the Roc-host/Roc-app portion, and the
|
||||
host author only cares about the Roc-host/C boundary when implementing the host.
|
||||
|
||||
Using this glue code, the Roc compiler can generate C header files describing the
|
||||
boundary. This not only gets us host compatibility with C compilers, but also
|
||||
Rust FFI for free, because [`rust-bindgen`](https://github.com/rust-lang/rust-bindgen)
|
||||
boundary. This not only gets us host compatibility with C compilers, but also
|
||||
Rust FFI for free, because [`rust-bindgen`](https://github.com/rust-lang/rust-bindgen)
|
||||
generates correct Rust FFI bindings from C headers.
|
||||
|
@ -14,17 +14,17 @@ $ cargo run --release Hello.roc
|
||||
|
||||
## Design Notes
|
||||
|
||||
This demonstrates the basic design of hosts: Roc code gets compiled into a pure
|
||||
This demonstrates the basic design of hosts: Roc code gets compiled into a pure
|
||||
function (in this case, a thunk that always returns `"Hello, World!"`) and
|
||||
then the host calls that function. Fundamentally, that's the whole idea! The host
|
||||
might not even have a `main` - it could be a library, a plugin, anything.
|
||||
Everything else is built on this basic "hosts calling linked pure functions" design.
|
||||
|
||||
For example, things get more interesting when the compiled Roc function returns
|
||||
a `Task` - that is, a tagged union data structure containing function pointers
|
||||
to callback closures. This lets the Roc pure function describe arbitrary
|
||||
chainable effects, which the host can interpret to perform I/O as requested by
|
||||
the Roc program. (The tagged union `Task` would have a variant for each supported
|
||||
a `Task` - that is, a tagged union data structure containing function pointers
|
||||
to callback closures. This lets the Roc pure function describe arbitrary
|
||||
chainable effects, which the host can interpret to perform I/O as requested by
|
||||
the Roc program. (The tagged union `Task` would have a variant for each supported
|
||||
I/O operation.)
|
||||
|
||||
In this trivial example, it's very easy to line up the API between the host and
|
||||
@ -39,6 +39,6 @@ Roc application authors only care about the Roc-host/Roc-app portion, and the
|
||||
host author only cares about the Roc-host/C boundary when implementing the host.
|
||||
|
||||
Using this glue code, the Roc compiler can generate C header files describing the
|
||||
boundary. This not only gets us host compatibility with C compilers, but also
|
||||
Rust FFI for free, because [`rust-bindgen`](https://github.com/rust-lang/rust-bindgen)
|
||||
boundary. This not only gets us host compatibility with C compilers, but also
|
||||
Rust FFI for free, because [`rust-bindgen`](https://github.com/rust-lang/rust-bindgen)
|
||||
generates correct Rust FFI bindings from C headers.
|
||||
|
@ -30,4 +30,4 @@
|
||||
```
|
||||
0. See [here](../README.md#examples) for the other examples.
|
||||
|
||||
**Tip:** when programming in roc, we recommend to execute `./roc check myproject/Foo.roc` before `./roc myproject/Foo.roc` or `./roc build myproject/Foo.roc`. `./roc check` can produce clear error messages in cases where building/running may panic.
|
||||
**Tip:** when programming in roc, we recommend to execute `./roc check myproject/Foo.roc` before `./roc myproject/Foo.roc` or `./roc build myproject/Foo.roc`. `./roc check` can produce clear error messages in cases where building/running may panic.
|
||||
|
@ -7,8 +7,8 @@
|
||||
|
||||
- How is AST data accessible to plugins?
|
||||
- How does plugin UI work (UI components, vector level, pixel-level)?
|
||||
- Given a selected expression, how do we show all plugins available that can visualize this
|
||||
expression or have an interactive widget to alter the expression (color picker). What does
|
||||
- Given a selected expression, how do we show all plugins available that can visualize this
|
||||
expression or have an interactive widget to alter the expression (color picker). What does
|
||||
this API look like?
|
||||
- use type driven UX? https://pchiusano.github.io/2013-09-10/type-systems-and-ux-example.html
|
||||
|
||||
@ -18,13 +18,13 @@
|
||||
+ zoomed out view should show type defs and function defs with folded body
|
||||
+ zooming in on function should unfold/show function body
|
||||
+ Traditional IDE's like ecplise can show an overwhelming amount of possible buttons/actions and views. Zoom levels can be used to prevent this excess of available options.
|
||||
|
||||
|
||||
- There should be a single editable text field to alter AST. This could be the same text field for entering commands, pressing a certain key could switch between command/plain text input into AST. Current part of AST that is being edited is highlighted.
|
||||
|
||||
- Hovering over expression should show button on left sidebar that allows you to pop out a pinned view of the expression.
|
||||
This pinned view could for example show all variants in a large type definition.
|
||||
Hovering over a type in a place other than the definition could show all variants, this hover view should also be capable of being pinned and moved around as desired.
|
||||
|
||||
|
||||
- UI interaction specification from which we can generate both e.g. a window with clickable buttons 'previuous' and `next` that also supports the voice commands `previuous` and `next`.
|
||||
|
||||
Next actions to take:
|
||||
|
@ -8,16 +8,16 @@ That’s why the logo is a bird. It’s specifically an [*origami* bird](https:/
|
||||
to [Elm](https://elm-lang.org/)’s tangram logo.
|
||||
|
||||
Roc is a direct descendant of Elm. The languages are similar, but not the same.
|
||||
[Origami](https://en.wikipedia.org/wiki/Origami) likewise has similarities to [tangrams](https://en.wikipedia.org/wiki/Tangram), although they are not the same.
|
||||
Both involve making a surprising variety of things
|
||||
from simple primitives. [*Folds*](https://en.wikipedia.org/wiki/Fold_(higher-order_function))
|
||||
[Origami](https://en.wikipedia.org/wiki/Origami) likewise has similarities to [tangrams](https://en.wikipedia.org/wiki/Tangram), although they are not the same.
|
||||
Both involve making a surprising variety of things
|
||||
from simple primitives. [*Folds*](https://en.wikipedia.org/wiki/Fold_(higher-order_function))
|
||||
are also common in functional programming.
|
||||
|
||||
The logo was made by tracing triangles onto a photo of a physical origami bird.
|
||||
It’s made of triangles because triangles are a foundational primitive in
|
||||
The logo was made by tracing triangles onto a photo of a physical origami bird.
|
||||
It’s made of triangles because triangles are a foundational primitive in
|
||||
computer graphics.
|
||||
|
||||
The name was chosen because it makes for a three-letter file extension, it means
|
||||
The name was chosen because it makes for a three-letter file extension, it means
|
||||
something fantastical, and it has incredible potential for puns.
|
||||
|
||||
# Different Ways to Spell Roc
|
||||
@ -29,4 +29,4 @@ something fantastical, and it has incredible potential for puns.
|
||||
|
||||
# Fun Facts
|
||||
|
||||
Roc translates to 鹏 in Chinese, [which means](https://www.mdbg.net/chinese/dictionary?page=worddict&wdrst=0&wdqb=%E9%B9%8F) "a large fabulous bird."
|
||||
Roc translates to 鹏 in Chinese, [which means](https://www.mdbg.net/chinese/dictionary?page=worddict&wdrst=0&wdqb=%E9%B9%8F) "a large fabulous bird."
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Running benchmarks
|
||||
|
||||
Install cargo criterion:
|
||||
Install cargo criterion:
|
||||
```
|
||||
cargo install --git https://github.com/Anton-4/cargo-criterion --branch main
|
||||
```
|
||||
@ -8,7 +8,7 @@
|
||||
```
|
||||
sudo sh -c 'echo 1 >/proc/sys/kernel/perf_event_paranoid'
|
||||
```
|
||||
run:
|
||||
run:
|
||||
```
|
||||
cargo criterion
|
||||
```
|
@ -576,14 +576,14 @@ mod test_reporting {
|
||||
indoc!(
|
||||
r#"
|
||||
── UNRECOGNIZED NAME ───────────────────────────────────────────────────────────
|
||||
|
||||
|
||||
I cannot find a `true` value
|
||||
|
||||
|
||||
1│ if true then 1 else 2
|
||||
^^^^
|
||||
|
||||
|
||||
Did you mean one of these?
|
||||
|
||||
|
||||
True
|
||||
Str
|
||||
Num
|
||||
@ -630,12 +630,12 @@ mod test_reporting {
|
||||
indoc!(
|
||||
r#"
|
||||
y = 9
|
||||
|
||||
|
||||
box = \class, htmlChildren ->
|
||||
div [ class ] []
|
||||
|
||||
|
||||
div = \_, _ -> 4
|
||||
|
||||
|
||||
box "wizard" []
|
||||
"#
|
||||
),
|
||||
@ -644,7 +644,7 @@ mod test_reporting {
|
||||
── UNUSED ARGUMENT ─────────────────────────────────────────────────────────────
|
||||
|
||||
`box` doesn't use `htmlChildren`.
|
||||
|
||||
|
||||
3│ box = \class, htmlChildren ->
|
||||
^^^^^^^^^^^^
|
||||
|
||||
@ -7042,7 +7042,7 @@ I need all branches in an `if` to have the same type!
|
||||
r#"
|
||||
C a b : a -> D a b
|
||||
D a b : { a, b }
|
||||
|
||||
|
||||
f : C a Nat -> D a Nat
|
||||
f = \c -> c 6
|
||||
f
|
||||
@ -7051,20 +7051,20 @@ I need all branches in an `if` to have the same type!
|
||||
indoc!(
|
||||
r#"
|
||||
── TYPE MISMATCH ───────────────────────────────────────────────────────────────
|
||||
|
||||
|
||||
The 1st argument to `c` is not what I expect:
|
||||
|
||||
|
||||
5│ f = \c -> c 6
|
||||
^
|
||||
|
||||
|
||||
This argument is a number of type:
|
||||
|
||||
|
||||
Num a
|
||||
|
||||
|
||||
But `c` needs the 1st argument to be:
|
||||
|
||||
|
||||
a
|
||||
|
||||
|
||||
Tip: The type annotation uses the type variable `a` to say that this
|
||||
definition can produce any type of value. But in the body I see that
|
||||
it will only produce a `Num` value of a single specific type. Maybe
|
||||
|
Loading…
Reference in New Issue
Block a user