>> I did not check nor fix 'faith.error', as I
>> never use it.  Also, do we still need it, now
>> that we have 'faith.error-match'?  One can
>> explicitly match against ".*" if they need
>> to.  That said, either way, this patch is
>> orthogonal to fixing or removal of the
>> 'error' function.

Oh, I missed this earlier. I think you're right that it can be removed;
we are still in the 0.1.x stage of the project, and on top of that it's
almost always a mistake not to check the contents of the error.

I'll go ahead and push this removal.

This is primarily meant for debugging; it allows you to use a repl to
see what's going on in the middle of a function and experiment with
whatever values are in scope interactively.

See the description in the documentation for details.
---
 reference.md          | 25 +++++++++++++++++++++++++
 src/fennel/macros.fnl | 19 ++++++++++++++++++-
 test/macro.fnl        | 14 +++++++++++++-
 3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/reference.md b/reference.md
index 61faef8..0a5985a 100644
--- a/reference.md
[message trimmed]

Hello everyone.

During yesterday's Fennel User Group meeting we discussed some ideas
about cleaning up the syntax for pattern matching when it comes to guard
clauses and `or` clauses. There was more or less broad agreement that
the current notation is not ideal:

    (case (foo)
      (where (or 1 2 3)) "a"
      (where [x y z] (and ready? x)) [y z]
      (where (or (x y) (y x)) (< x y)) "c"
      _ :no-match)

The main reason is that patterns beginning with `where` look like a call

Hello team Fennel.

Just wanted to let everyone know that we have our monthly Fennel user
group tomorrow:

  https://fennel-lang.org/events

We meet on jitsi at 1000 US Pacific / 1700 UTC

  https://meet.jit.si/FennelUserGroup

Recently someone added support for an ics file so you can import it into
your calendar if that's your jam:

Andrey <andreyorst@gmail.com> writes:

>> Sorry, I don't think this is easy! This sounds really difficult, because
>> "what's in the module" will frequently depend on modules which will not load
>> in the compiler sandbox.
>
> Honestly, I never fully understood why we do sandboxing of the compiler
> in the first place.  It, however, limits interesting things that can be done with
> macros, like conditional based on environment variable for example.

Well, have you taken a look at fennel-ls? If you compare the quality of
the static analysis from fennel-ls vs the Clojure language server, the
Fennel one is dramatically better despite being much less code. This is
only possible because it can do static analysis on the expanded code,

Nice catch; thanks. Applied and pushed. Sorry for the delay.

-Phil

"J. Ryan Stinnett" <jryans@gmail.com> writes:

> -                [:a {:href "https://matrix.to/#/fennel:matrix.org"}
> +                [:a {:href "https://matrix.to/#/#fennel:matrix.org"}

Applied and pushed; thanks!

-Phil

Andrey Listopadov <andreyorst@gmail.com> writes:

> I've been tinkering with my libraries for the last week or so, porting
> them to the single file approach, where both macros and functions are
> exported from the same file with a small eval-compiler and macro-loaded
> hack.  For what it's worth it works fairly well, allowing me to
> distribute my libraries easier than before.  And once again it got me
> thinking how we can make macros more like macros in other lisps.

Thanks for posting your thoughts on this. I agree that the current
status quo is not ideal, and we should work towards a solution which
makes things smoother for macro authors while preserving the
transparency of the existing system.

Andrey <andreyorst@gmail.com> writes:

> I can see this less than an ideal solution, as it means that proto-repl
> isn't generic enough. Phil, do you think we can offer fennel-the-module
> as a field in the ___repl___ table?  This way, the protocol will not 
> be required to require anything.  Given that the REPL requires the
> fennel module to work I assume it's OK to reference it in the ___repl___
> WDYT?

I would be fine adding the module or at least the module name to this
table if you still need it. Is it still needed or did you get this taken
care of?

-Phil

Colin Woodbury <colin@fosskers.ca> writes:

> Hi everyone, I'm trying to discover a way to load Fennel functions
> into a REPL which reference global symbols provided only at
> runtime. For example, the built-in functions provided by the TIC-80
> environment. Currently, if you try to load a Fennel function 'A' which
> calls a TIC-80 function 'B', the compiler will complain that 'B' is
> nowhere to be seen, and thus 'A' can't be loaded.
>
> While that's normally desirable behaviour, it would be convenient if
> there were a way to tell the compiler to "trust me" or otherwise
> overlook the issue.

If you just to disable all globals checking for a given repl session you