Fixes the issue described here:
https://lists.sr.ht/~technomancy/fennel/%3Cb2c26bc9-f3fd-4aa7-802b-ece4096e2704@alterae.online%3E

Per an option mentioned in that discussion, utf8-len from fennel.view
was copied in. It's used as a fallback in slength if utf8 isn't
available.

Before patch:

(λ way-too-many-arguments [_first
                            _second
                            {: foo
                             : bar
                             : baz
[message trimmed]

> Anyway, I thought people might be interested in reading some sample
> code. I ran into a few bugs in moonmint, but they were easy to fix, and
> I've been impressed with how straightforward it was to build a quick
> application; my search engine is under 200 lines including basic
> crawling and indexing.

Thanks for sharing this! It was a pleasant read.

~jship

Lambda functions currently do not nil-check the table argument itself
when that table is matched. For example, this function and its Lua
output:

>> ,compile (lambda foo [{: bar} quux] (+ bar quux))
local function foo(_1_, quux)
  local bar = _1_["bar"]
  _G.assert((nil ~= quux), "Missing argument quux on unknown:1")
  _G.assert((nil ~= bar), "Missing argument bar on unknown:1")
  return (bar + quux)
end

Only the pieces of the match are nil-checked but not the table itself,
which makes errors not as clear as they could be when the table is nil:

On Sat Apr 27, 2024 at 2:04 PM EDT, Phil Hagelberg wrote:
> Yes, unfortunately we have to do some compilation magic to work around
> the fact that Lua has statements and multiple values. We call it IIFE, or
> immediately-invoked function expressions. In an expression-only
> language, there are certain constructs that as you've observed can't be
> compiled directly to statements without some kind of wrapper to protect it.

Thank you - learning of that IIFE term is helpful. Is my understanding
correct that the last piece in a 'values' uses an IIFE as a safe-guard
in case that last piece itself returns multiple values?

> There's more we could do to continue to improve it, but this is a really
> good start. If you're interested in working towards this let us know and
> maybe we can point you in the right direction.

When individual values of a multiple return have their own bindings,
I've observed that the resulting Lua has the last return value's
computation wrapped in a function rather than a do block.

Is this due to a nuance/operational detail of Lua?

I've included examples below going one from one return to three returns:

$ fennel -c <(echo '(local a (values (let [a 1] a)))')
local a
local function _1_(...)
  local a0 = 1
  return a0
end

The build seems to have failed due to the patch containig the removal of
a few trailing spaces in the docs. It applies successfully locally via:

$ git am --whitespace=fix ~/path/to/mbox

~jship

---
Also removes a few trailing spaces.

 macros.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/macros.md b/macros.md
index e93cf74..0091c57 100644
--- a/macros.md
+++ b/macros.md
@@ -134,7 +134,7 @@ instead of symbols. It would look like this when run:
 ;; [:if [:ready-to-go?]
 ;;       [:do [:make-it-so!]
 ;;            [:if [:ready-to-go?]
[message trimmed]

On Tue Apr 23, 2024 at 10:15 PM EDT, Phil Hagelberg wrote:
> Yes; this is because nil by definition cannot be stored in Lua tables.
> The AST is made of tables, and in the context of a table, nil is nothing.

This is very helpful and makes a lot of sense in hindsight.

> Sure; instead of using nil, use a symbol with the name "nil":
>
>     (fn init-kind [kind]
>       (case kind
>         :foo []
>         :bar (sym "nil")
>         _ (error "invalid kind")))
>

I'm learning Fennel's macro system and have hit a confusing case
regarding an intentional nil I'm trying to produce in the generated
code. My contrived macro file looks like this:

  ;; fennel-ls: macro-file

  (fn init-kind [kind]
    (case kind
      :foo []
      :bar nil
      _ (error "invalid kind")))

  (fn with-thing [[kind name] & body]
    `(let [,name ,(init-kind kind)]

On Fri Apr 12, 2024 at 3:53 PM EDT, Andrey Listopadov wrote:
> It's a more portable (across lua implementations) way of writing a
> semicolon.

Ahhh, thank you!