Andrey Listopadov <andreyorst@gmail.com> writes:

> To summarize:
>
> - Relative require is very hard to get properly (even after I've written
>   an extensive tutorial on the topic);

I agree that we need to improve relative-require. We've got it to the
point where it's possible to use, but we need to improve it such that
it's obvious how to do it and that you don't have to look it up every
time. There was a proposal here which I'd love to see prototyped and
moved forward: https://todo.sr.ht/~technomancy/fennel/103

> - Libraries, providing both runtime and macro components are hard to use

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

> 1. How is the compiler smart enough to make this:
>     ``` lua
>     {:ast (setmetatable out (getmetatable t))
>     :leaf "return setmetatable(out, getmetatable(t))"}]
>     ```
>   A dumb compiler would do this:
>   ``` lua
>   local __tmp0 = getmetatable(t)
>   local __tmp1 = setmetatable(out, __tmp0)
>   return __tmp1
>   ```

Andrey Listopadov <andreyorst@gmail.com> writes:

> That's a neat idea! Although I think we're talking about different
> features :D I'll try to explain in a bit more details below what I've
> envisioned.

Yeah, I think it's important to separate out the compile-time data from
the runtime data. The syntax highlighting functionality for identifying
macros could be handled by a separate compile-time dump, but the repl
locals couldn't be done without runtime info.

IMO we should avoid using the word scope for the runtime
feature. Perhaps just calling it "module locals" for the feature which
exposes the data, and ",enter" for the repl command?

Andrey Listopadov <andreyorst@gmail.com> writes:

> I think we can start with something small and simple, and build from it.
> For example, when we (re)load a module, we can create a table entry,
> like:
>
> {:module-name {:locals {:local-name :the-value}}

I was thinking that we would need to make sure that the table format we
use would be extensible enough that we could add more targeted
per-position data later on. But thinking about it more, I think the
targeted scope info should be queried by making a fresh compile every
time, as a function call rather than a table lookup. So it doesn't have
to use the same table.

Andrey Listopadov <andreyorst@gmail.com> writes:

> During the fennel user group meeting we had a discussion about scopes,
> and the problem of highlighting macros, and providing finer completions
> in the editor, and came up with an idea of how this could be improved.

There's two main drivers for this, both around improving tooling. One is
the ability to target repl commands at a file. Completion is probably
the most important one, but we could also possibly find definitions
based on the scope table.

The other is to get insight into the macros in play, which is useful for
syntax highlighting.

This introduces a utils.len function which will give the length of a
string in characters when that is available (lua 5.3+ or older luas
with a backport of the utf8 library, such as love2d) but falls back to
bytes otherwise. This means that the pinpoint ------^ feature in error
messages will make a best-effort to calculate the offsets correctly
but can sometimes be wrong. Even when the utf8 library is available,
it cannot reliably tell you the *width* of a string; for
instance (utf8.len "วัด") gives 3, which is the number of codepoints in
the string, but the string is only 2 characters wide for purposes of
calculating the column.

Currently the attempt to be utf8-aware is only done in the error
pinpointing code. The parser column number information is strictly
byte-based.
[message trimmed]

This will help make fennel.friend's implementation much cleaner, and
it will also help editor integration tooling.
---
 api.md                | 10 ++++++----
 changelog.md          |  1 +
 src/fennel/parser.fnl | 31 ++++++++++++++++---------------
 test/parser.fnl       | 19 ++++++++++++++++++-
 4 files changed, 41 insertions(+), 20 deletions(-)

diff --git a/api.md b/api.md
index 0461df4..e39cb20 100644
--- a/api.md
+++ b/api.md
@@ -253,8 +253,9 @@ Note that lists are compile-time constructs in Fennel. They do not exist at
[message trimmed]

XeroOl <xerool@protonmail.com> writes:

> Antifennel will always include the step parameter to the for loops it
> generates, regardless of whether or not the step is necessary.
> This creates output that is technically correct, but isn't formatted
> in an ideal way. After this patch, antifennel will generate loops like
> (for [i 1 10] ...) instead of (for [i 1 10 1] ...) if the step is 1.

Thanks; this change looks good. I've applied and pushed.

-Phil

Andrey Listopadov <andreyorst@gmail.com> writes:

> (print [340.29 ;; speed of sound
>         1337])
>
> If this becomes:
>
> (print [340.29
>         ;; speed of sound
>         1337])
>
> Given that the comment at the end of the line is usually about the line,
> and the comment that stands on its own line is usually about the next
> line there's a possibility of taking that this comment applies to 1337.

Went ahead and applied this; thanks.

-Phil