Three reasons:
1. This same behavior is not documented on the `next` function
2. This function does not throw the error directly,
it only throws an error because `next` does.
3. Following the same idea as the previous commit, this behavior is
more or less implementation-defined for nonsensical types
> In dynamic languages, the usual idea is garbage in, garbage out.
Various other documentation cleanup.
> Remove the try. In dynamic languages, the usual idea is garbage in, garbage out. You misunderstood my point about the type error. “Test” functions are not special in that regard.
> - @bakpakin
This is just documentation of existing behavior, it does not change anything.
The reason index-of throws a type error on non-iterable types is because `next` does.
This is hardcoded into the JOP_NEXT opcode (see src/core/value.c:janet_next_impl).
Unfortunately, there is currently no corresponding `iterable?` check.
Note this actually changes behavior from a thin wrapper over `index-of`.
This is because `(index-of 3 3)` throws "error: expected iterable type, got 3"
This is significantly clearer than using (not (nil? (index-of col val)))
Most major programming languages offer some sort of contains function (Python, Java, C, Rust).
The only exception I know of is C.
When using make to build an rpm, the current symlink is
created with an absolute path to the buildroot as causes
the make install target to fail with:
error: Symlink points to BuildRoot: /usr/include/janet.h -> /home/stephen/rpmbuild/BUILDROOT/janet-1.23.0-3.x86_64/usr/include/janet/janet.h
We can create the link relatively which makes this more
portable, where:
ln -sf -t '/home/stephen/rpmbuild/BUILDROOT/janet-1.23.0-3.x86_64/usr/include' janet.h janet/janet.h
Resulting in the following symlink:
ls -la BUILDROOT/usr/include/janet.h
lrwxrwxrwx. 1 stephen stephen 13 Jul 2 08:17 BUILDROOT/usr/include/janet.h -> janet/janet.h
This symlink can then be properly packaged without path
issues.
Signed-off-by: Stephen Hassard <steve@hassard.net>
