WA, USA
tryin' to catch the last train out of Omelas
From Phil Hagelberg to ~technomancy/fennel
>> 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.
From Phil Hagelberg to ~technomancy/fennel
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]
From Phil Hagelberg to ~technomancy/fennel
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
From Phil Hagelberg to ~technomancy/fennel
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:
From Phil Hagelberg to ~technomancy/fennel
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,
From Phil Hagelberg to ~technomancy/fennel
Nice catch; thanks. Applied and pushed. Sorry for the delay. -Phil
From Phil Hagelberg to ~technomancy/fennel
"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
From Phil Hagelberg to ~technomancy/fennel
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.
From Phil Hagelberg to ~technomancy/fennel
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
From Phil Hagelberg to ~technomancy/fennel
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